Re: propagating the value of the build-profiles field to Packages and Sources files

[Guillem Jover <guillem@debian.org>]

Hi!

On Mon, 2014-04-21 at 14:26:25 +0200, Johannes Schauer wrote:
> I now believe the former option to be the superior one. As Raphaël Hertzog
> pointed out initially, which binary packages builds with what arch or profile
> is a property of the source package. Thus, the information should become part
> of the Package-List field. If it would be part of the Packages file, then one
> would miss out on information on binary packages that happen not to build on
> the architecture for which one selected a Packages file. This leaves us with
> storing the information in the Sources file and the Package-List field seems
> good for that.
> 
> I found dpkg commits e3a9083f and 8bbd76cc which showed that the information
> for the architecture was already part of dpkg at some point. All archs were
> concatenated with a comma. The same could be done for build profiles.
> 
> Here is the trivial patch that enables both (and partly reverts commit
> 8bbd76cc):
> 
> --- a/scripts/dpkg-source.pl
> +++ b/scripts/dpkg-source.pl
> @@ -267,7 +267,11 @@ if ($options{opmode} =~ /^(-b|--print-format|--(before|after)-build|--commit)$/)
>         my $prio = $pkg->{'Priority'} || $src_prio;
>         my $type = $pkg->{'Package-Type'} ||
>                 $pkg->get_custom_field('Package-Type') || 'deb';
> -       push @pkglist, sprintf('%s %s %s %s', $p, $type, $sect, $prio);
> +       my $arch = $pkg->{'Architecture'};
> +       $arch =~ s/\s+/,/g;
> +       my $profiles = $pkg->{'Build-Profiles'} || 'all';
> +       $profiles =~ s/\s+/,/g;
> +       push @pkglist, sprintf('%s %s %s %s %s %s', $p, $type, $sect, $prio, $arch, $profiles);
>         push(@binarypackages,$p);
>         foreach (keys %{$pkg}) {
>             my $v = $pkg->{$_};
> 
> If the Build-Profiles field is empty, the special value 'all' is substituted,
> indicating that this binary package builds for all profiles (including none at
> all).
> 
> Which software would be affected by such an extension of the Package-List
> field? I found bug#619131 which seems to indicate that maybe something in the
> build infrastructure will break with such an addition?
> 
> What do you think of this solution?

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.

The main thing that might break could be dak, but that's why I'm
planning to upload dpkg itself with a .dsc file generated with the
new version, so that if dak does not like it, that would hopefully
get rejected, although from the start it was communicated that
Package-List was to have optional entries after the initially defined
ones.

For dpkg 1.17.8 I'm planning to create dsc(5) and dpkg-changes(5) or
similar to document those formats, as there are currently fields not
documented elsewhere in dpkg (except for the commit logs).

Thanks,
Guillem