Hi!
On Thu, 2011-03-24 at 14:01:26 +0000, Raphaël Hertzog wrote:
> commit 014672432452a6f6a18c44e733fece7938685370
> Author: Raphaël Hertzog <hert...@debian.org>
> Date: Thu Mar 24 14:39:56 2011 +0100
>
> dpkg-source: add new Package-List field to .dsc files
>
> This field has been requested by ftpmasters so that they can install
> overrides for all binary packages as soon as they have approved
> the source package. It contains a the list of packages that the source
> can build along with their sections and priorities.
I don't really feel comfortable including this for the next release. As
I mentioned some days ago on IRC I consider this was rushed in while
discussions were still going on, concerns had been brought up, and it
being so close to the upload.
I'd like us to agree to avoid in general doing design work for public
interfaces directly on git master while there's no clear consensus yet,
because I think it's more costly than pondering for a bit longer.
Having to consider reverting a change or proposing a different solution
seems more energy consuming this way too, more so when there's an
upload imminent. :)
It seems to me it has rapidly become a bit of a dumping ground for
several items of data people have seen the opportunity to get their
hands on. Some of which might be more appropriate to place somewhere
else or in some other form.
For example, part of the architecture request was to distingush if the
source can produce arch:all binaries, as that's currently not
distinguishable when the source also produces an arch:any package. The
correct solution here seems to me to be to not collapse ‘all’ into ‘any’
on the .dsc Architecture field, building up on the fix for a related
issue in commit 3624a4b0eb5499f367c1d8077240f151903cd70a. In addition
‘any’ here implying ‘all’ takes a different meaning than what it usually
has, so that would disambiguate it too. (Policy would need updating,
but I don't see any problem with that.)
I also agree with Bernhard that the source Section and Priority belong
in their own fields, and thus there's really no need to have such
entry in such binary packages list.
Regarding regeneration of control files, one thing I don't think has
been considered is Priority changing depending on architecture, which
while (AFAIK) not supported by the Debian archive software yet, it's
clearly a limitation that I hope will get fixed eventually. And while
substvars cannot really be used in Priority/Section fields, because
they need to get read by dpkg-genchanges, I don't see anything
conceptually wrong with changing them at build time when generating
the binary packages, which would imply the information in the
Package-List would be incorrect.
Also the request to list all binary package Section/Priority pairs was
due to sources producing different binary package names depending on
the architecture which seems to me to be the exception rather than the
rule, together with the additional cost of having to modify all archive
software to filter out that new field, and while I really understand the
need behind the request, it makes me think it's worth pondering about
this a bit more.
So I'd like to either revert the two commits or disable the field
generation for now (like in the attached patch), and reconsider this
for 1.16.1.
thanks,
guillem
diff --git a/scripts/dpkg-source.pl b/scripts/dpkg-source.pl
index eb020d0..76c701d 100755
--- a/scripts/dpkg-source.pl
+++ b/scripts/dpkg-source.pl
@@ -291,6 +291,7 @@ if ($options{'opmode'} =~ /^(-b|--print-format|--(before|after)-build)$/) {
$src_sect, $src_prio,
join(',', @sourcearch));
$fields->{'Package-List'} .= "\n" . join("\n", sort @pkglist);
+ delete $fields->{'Package-List'};
# Scan fields of dpkg-parsechangelog
foreach $_ (keys %{$changelog}) {
