Hi everybody,
Quoting Johannes Schauer (2014-03-20 08:40:05)
> So maybe this brings us back to encoding the Architecture as well as the
> Build-Profiles field information in the Package-List field of the source
> package as suggested by Raphaël Hertzog?
>
> Or maybe two new fields would solve the problem along the lines of
> Builds-With-Architecture and Builds-With-Build-Profiles?
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?
cheers, josch
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140421122625.26701.6949@hoothoot
