Re: propagating the value of the build-profiles field to Packages and Sources files
Quoting Johannes Schauer (2014-04-21 16:31:13)
> Quoting Guillem Jover (2014-04-21 16:04:17)
> > Sorry for not mentioning before, I had already locally a very similar patch,
> > which will be included in 1.17.7 to be uploaded in few minutes, but using a
> > key=value1,value2 format instead, so that the new stuff can appear in any
> > order and it's more clear what's it about. With «arch» and «profile» keys,
> > both being in principle optional, although «arch» will always get generated,
> > and «profile» will only be generated if the package contains a Build-Profiles
> > field; but I don't think defaulting to “all” would be future-proof, if a key
> > with an empty value would really be desired we could always emit it, because
> > that should be safe and unambiguous.
> > I'm also using join and split instead of s/// because otherwise a
> > comma might appear at the end with stuff like "foo bar quux ".
> > I've added support for Build-Profiles too, but only to be accepted in
> > the binary package stanzas on debian/control.
> thanks a lot! Sounds awesome :)
> Just in case you also already fixed that, I was currently preparing a patch
> which fixes the following two problems:
> dpkg-source: warning: unknown information field 'Build-Profiles' in input data in package's section of control info file
> Where the fix seems to have been to simply allow the Build-Profiles field in
> CTRL_INFO_PKG and:
> dpkg-genchanges: warning: package builds-only-stage1 in control file but not in files list
> Where the fix is a bit more involved because it requires checking if the
> currently active profiles lead to the binary package being built or not
> depending on the value of the Build-Profiles field. To that end I added a new
> function debprofile_is (as an equivalent to debarch_is) to
> scripts/Dpkg/BuildProfiles.pm and use it accordingly in
> scripts/dpkg-genchanges.pl. But there might be a more elegant solution because
> debprofile_is duplicates the logic of profile_is_concerned in
> scripts/Dpkg/Deps.pm with the difference that there is no "profile." prefix to
> take care of.
I have not managed to solve this issue in a satisfactory manner and am too
embarrassed to show what I came up with to people who actually know how to
write perl :D
Thus I created bug#758191 to keep track of this issue.