Processed: Bug#619131 marked as pending
Processing commands for cont...@bugs.debian.org: tag 619131 pending Bug #619131 [dpkg-dev] dpkg-source: Add more binary package information to .dsc Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. -- 619131: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619131 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#619131: marked as pending
tag 619131 pending thanks Hello, Bug #619131 reported by you has been fixed in the Git repository. You can see the changelog below, and you can check the diff of the fix at: http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=8bbd76c --- commit 8bbd76cc98360c20ff8ca660ab1d53234608ff92 Author: Raphaël Hertzog hert...@debian.org Date: Sat May 28 15:12:58 2011 +0200 dpkg-source: reenable the Package-List field But drop the Architecture column since we have no clear use case yet. It can always be added later on. Parsers should treat the field as an extendable one. They shall ignore supplementary columns that they do not know. Also drop the source line, it's not needed since the dsc file describes the source package already (source section and priority are not currently exported in dedicated fields but they can be added later if we start having a need for this information). diff --git a/debian/changelog b/debian/changelog index c487045..16aa463 100644 --- a/debian/changelog +++ b/debian/changelog @@ -21,6 +21,10 @@ dpkg (1.16.1) UNRELEASED; urgency=low internal files in /var/lib/dpkg/info/triggers/. Closes: #525160 * Avoid a perl warning in dpkg-gensymbols when no symbols file has been generated (because it would have been empty). Closes: #626684 + * Reenable the Package-List field but drop the Architecture column since we +have no clear use case yet. It can always be added later on. +Also drop the source line since it duplicates other fields. +Closes: #619131 [ Guillem Jover ] * Install deb-src-control(5) man pages in dpkg-dev. Closes: #620520 -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#619131: marked as pending
Hi!
On Thu, 2011-03-24 at 14:01:26 +, 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}) {
Bug#619131: marked as pending
Hi Guillem, On Fri, 01 Apr 2011, Guillem Jover wrote: 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. Sure, I just tried to please ftpmasters by including it ASAP. I did ask for feedback on -policy because of the short timing to try to have more eyes on this. My initial concerns had to do that it was really a field just for ftpmasters. The section/priority information alone is not so important and it seemed to me to be a waste of adding this field for this usage alone. Once 3 different people mentionned the architecture information as useful to export, I got convinced that the field can be more generally useful and thus went ahead with implementing it. 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 Bernhard R. Link mentionned another usage where the architecture value of each individual field is useful: http://lists.debian.org/debian-policy/2011/03/msg00156.html 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. I don't see where this reasoning will bring you. There are no cases like this currently, and a Package-List that is incorrect in term of an incorrect priority field for a subset of architectures is really not a big deal. On the opposite, if we really want to implement the request of ftpmasters, and if you want to support different priorities per package per arch, we're going to end up with an over-engineered solution for almost zero gain. 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. Once I added the architecture field, it made the field more widely useful and thus I assumed it would not be dropped any more. But ok, we can take some more time to discuss and push it for 1.16.1. 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. I've done it. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: Bug#619131 marked as pending
Processing commands for cont...@bugs.debian.org: tag 619131 pending Bug #619131 [dpkg] dpkg: new field in .dsc Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. -- 619131: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619131 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#619131: marked as pending
tag 619131 pending thanks Hello, Bug #619131 reported by you has been fixed in the Git repository. You can see the changelog below, and you can check the diff of the fix at: http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=0146724 --- 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. It looks like this: Package-List: src:foo admin optional foo admin optional foo-common admin optional udeb:foo-udeb debian-installer extra diff --git a/debian/changelog b/debian/changelog index bf542c9..427bfa6 100644 --- a/debian/changelog +++ b/debian/changelog @@ -92,6 +92,9 @@ dpkg (1.16.0) UNRELEASED; urgency=low spotting it. * Use the correct mtime when installing a file with statoverrides. LP: #739179 + * Add new Package-List field to .dsc files as requested by ftpmasters. +It contains a the list of packages that the source builds along with +their sections and priorities. Closes: #619131 [ Jonathan Nieder ] * Remove support for use of synchronous sync(2), due to its pernicious -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
