Debian Bug report logs - #619131
dpkg-source: Add more binary package information to .dsc

version graph

Package: dpkg-dev; Maintainer for dpkg-dev is Dpkg Developers <debian-dpkg@lists.debian.org>; Source for dpkg-dev is src:dpkg.

Reported by: Joerg Jaspert <joerg@ganneff.de>

Date: Mon, 21 Mar 2011 14:54:05 UTC

Severity: wishlist

Fixed in version dpkg/1.16.1

Done: Guillem Jover <guillem@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, ftpmaster@debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#619131; Package dpkg. (Mon, 21 Mar 2011 14:54:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Joerg Jaspert <joerg@ganneff.de>:
New Bug report received and forwarded. Copy sent to ftpmaster@debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>. (Mon, 21 Mar 2011 14:54:08 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Joerg Jaspert <joerg@ganneff.de>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: dpkg: new field in .dsc
Date: Mon, 21 Mar 2011 15:44:53 +0100
[Message part 1 (text/plain, inline)]
Package: dpkg
Version: 1.15.8.10
Severity: normal
Heyho,

we want a new field to be put into .dsc files please. This should be a
list of all "override" entries for this package. That is, a list
consisting of every single binary and one line for the source package
itself.

The list should be handled similar to the Files: field, listing every
single binary *and* its overrides that CAN be built by this
source. (Unlike for example the Binaries field in .changes only listing
what was built on that particular architecture)

Assuming we name the field "Package-Set", a hypotetical linux-4.2 source
could look like:

[... whatever else is in a dsc ...]
Package-Set:
 linux-tools-4.2.21 kernel optional
 xen-linux-system-4.2.21-2-xen-amd64 kernel extra
 linux-headers-4.2.21-2-parisc-smp kernel optional
 linux-headers-4.2.21-5-all-ia64 kernel optional
 linux-image-4.2.21-2-amd64 kernel required
 [... all the rest of the three million and one entries ...]

As we just had a short discussion on irc, let me bring some points from
there:

I would love if the source itself also appears in that field, but could
deal also without. Having the source in would mean there is one single
place to run through for ALL possible override entries. Having it out
means looking at Source: too. If its implemented WITH source, then the
definition should be like "the first line is the source entry, the
package name prefixed with src:" and it should always be only one such
line.

buxy mentioned to optimize this by leaving out all the binary entries
that are using the "default overrides". I don't much like this for two
reasons: First you would need to add two more fields, section/priority
to show what those defaults are, they aren't in the dsc now. Second the
assumption that one can go through "Package-Set" and have all of them
would fail, one would actually have to do the work of merging
Package-Set together with a merge of binary/section/priority.

The argument of saving something in terms of sizes is not much
convincing to me, looking at the usual size of stuff we are dealing with
anyways. A few more lines of text dont seem to matter, imo. It is also
easier to work with them in shell scripts.

And the background for this stunt: This way we can process NEW adding
overrides for every package, not requiring a new NEW run for every
single arch of packages that build different names on different
architectures. While we COULD do it by extracting the source, looking at
the debian/control and parsing that, this gets increasingly hard with
different source formats, possible source tarballs being elsewhere
(think of -2 uploads and source in pool) and other processing
trouble. Compared to the relative ease dpkg-* can do it at build time it
seems better to do it there. (also, this way others profit too)

Oh, and just before I hit send:
<buxy> Ganneff: my current preference for the field name goes to "Categorization"

--
bye, Joerg
Some NM:
>A developer contacts you and asks you to met for a keysign. What is
>your response and why?
Do you like beer? When do we meet? [...]
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#619131; Package dpkg. (Wed, 23 Mar 2011 18:57:10 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ansgar Burchardt <ansgar@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Wed, 23 Mar 2011 18:57:10 GMT) Full text and rfc822 format available.

Message #10 received at 619131@bugs.debian.org (full text, mbox):

From: Ansgar Burchardt <ansgar@debian.org>
To: 619131@bugs.debian.org
Subject: Re: dpkg: new field in .dsc
Date: Wed, 23 Mar 2011 19:55:40 +0100
For the override file we also need to know which binaries are udeb's.
I suggest using "udeb:<package>" in this case (analogous to
"src:<package>").

Regards,
Ansgar




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#619131; Package dpkg. (Thu, 24 Mar 2011 04:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 24 Mar 2011 04:39:03 GMT) Full text and rfc822 format available.

Message #15 received at 619131@bugs.debian.org (full text, mbox):

From: Guillem Jover <guillem@debian.org>
To: Joerg Jaspert <joerg@ganneff.de>, 619131@bugs.debian.org
Subject: Re: Bug#619131: dpkg: new field in .dsc
Date: Thu, 24 Mar 2011 05:36:27 +0100
severity 619131 wishlist
thanks

On Mon, 2011-03-21 at 15:44:53 +0100, Joerg Jaspert wrote:
> we want a new field to be put into .dsc files please. This should be a
> list of all "override" entries for this package. That is, a list
> consisting of every single binary and one line for the source package
> itself.

Just a nomenclature note here, overrides is what the archive (whatever
implementation that might be, dak, dpkg-scanpackages, etc) applies to
the fields from the binary/source packages, which is the original
source of the information.

> And the background for this stunt: This way we can process NEW adding
> overrides for every package, not requiring a new NEW run for every
> single arch of packages that build different names on different
> architectures. While we COULD do it by extracting the source, looking at
> the debian/control and parsing that, this gets increasingly hard with
> different source formats, possible source tarballs being elsewhere
> (think of -2 uploads and source in pool) and other processing
> trouble. Compared to the relative ease dpkg-* can do it at build time it
> seems better to do it there. (also, this way others profit too)

Neither of these are truly possible w/o breaking current assumptions.
There's no guarantee at all that the binary stanzas in debian/control
correspond with what will be shipped in the .changes file. The only
stanza that is guaranteed to be constant is the source one.

In addition it's currently supported to ship less packages than the
ones listed in debian/control, even if dpkg-genchanges will warn about
it. And besides changing or adding new binary stanzas to debian/control,
adding new files not present in debian/control has been supported for a
long time via dpkg-distaddfile.

(I've just fixed an unused variable usage in dpkg-genchanges due to
files added by dpkg-distaddfile in some conditions, which I'll include
in my next push.)

Anyway, recording entries on the archive for things that might never
appear seems a bit crufty, but you are the ones handling dak. Also
I'm not sure how you are currently handling the NEW processing
regarding the overrides, but from what I've seen I've got the
impression package sections and priorities are not usually overriden
on that stage (as they used to be)? If that's the case then the
archive software could as well initialize the overrides automatically
with the entries from the binary packages in the .changes file.

regards,
guillem




Severity set to 'wishlist' from 'normal' Request was from Guillem Jover <guillem@debian.org> to control@bugs.debian.org. (Thu, 24 Mar 2011 04:39:04 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#619131; Package dpkg. (Thu, 24 Mar 2011 07:24:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 24 Mar 2011 07:24:03 GMT) Full text and rfc822 format available.

Message #22 received at 619131@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Joerg Jaspert <joerg@ganneff.de>, 619131@bugs.debian.org, Guillem Jover <guillem@debian.org>
Subject: Re: Bug#619131: dpkg: new field in .dsc
Date: Thu, 24 Mar 2011 08:20:21 +0100
On Mon, 21 Mar 2011, Joerg Jaspert wrote:
> buxy mentioned to optimize this by leaving out all the binary entries
> that are using the "default overrides". I don't much like this for two
> reasons: First you would need to add two more fields, section/priority
> to show what those defaults are, they aren't in the dsc now. Second the
> assumption that one can go through "Package-Set" and have all of them
> would fail, one would actually have to do the work of merging
> Package-Set together with a merge of binary/section/priority.

I would not add supplementary fields, the "default overrides" would be
those in the first line that refers to the source package and this line
would not be optional.

> The argument of saving something in terms of sizes is not much
> convincing to me, looking at the usual size of stuff we are dealing with
> anyways. A few more lines of text dont seem to matter, imo. It is also
> easier to work with them in shell scripts.

The size of the individual .dsc is not anything I would be worried of
but the cumulated size in Sources.gz is more of a concern. Obviously
we might decide to not store this field there but that means modifying
all software that can generate those.

> Oh, and just before I hit send:
> <buxy> Ganneff: my current preference for the field name goes to "Categorization"

I think it's going to be "Package-List" because Package-Set could be
slightly confusing with the terminology we use internally for a set of MultiArch:
same package.

On Thu, 24 Mar 2011, Guillem Jover wrote:
> > And the background for this stunt: This way we can process NEW adding
> > overrides for every package, not requiring a new NEW run for every
> > single arch of packages that build different names on different
> > architectures. While we COULD do it by extracting the source, looking at
> > the debian/control and parsing that, this gets increasingly hard with
> > different source formats, possible source tarballs being elsewhere
> > (think of -2 uploads and source in pool) and other processing
> > trouble. Compared to the relative ease dpkg-* can do it at build time it
> > seems better to do it there. (also, this way others profit too)
> 
> Neither of these are truly possible w/o breaking current assumptions.
> There's no guarantee at all that the binary stanzas in debian/control
> correspond with what will be shipped in the .changes file. The only
> stanza that is guaranteed to be constant is the source one.
> 
> In addition it's currently supported to ship less packages than the
> ones listed in debian/control, even if dpkg-genchanges will warn about
> it. And besides changing or adding new binary stanzas to debian/control,
> adding new files not present in debian/control has been supported for a
> long time via dpkg-distaddfile.

Note that the field is going to be in the .dsc not in the .changes. Note
also that automatically modifying debian/control at build time has been
frowned upon for a long time (and forbidden by the ftpmasters in their
review). When debian/control is automatically generated, it's always done
manually before the source build so that the source contains a matching
list of packages in debian/control.

In practice, dpkg-distaddfile is mainly used manually to upload
non-packages (debian-installer images, debtags db, etc.).

So I think it's ok to go ahead with the assumption that all packages that
we care about are listed in debian/control.

> I'm not sure how you are currently handling the NEW processing
> regarding the overrides, but from what I've seen I've got the
> impression package sections and priorities are not usually overriden
> on that stage (as they used to be)? If that's the case then the
> archive software could as well initialize the overrides automatically
> with the entries from the binary packages in the .changes file.

AFAIK any package which does not appear in the overrides file is
considered NEW and triggers the corresponding review.

Thus they want to set the overrides for all the possible binaries as soon
as they have reviewed the source package so that each linux-2.6 upload
does not trigger NEW but only the first one with sources. They do not have
all the .debs at this point so can't extract the priorities.

They have a list of binary packages though and could add the entries with
a special value which means "auto-set with the first value seen for this
package". Ganneff, have you considered doing this?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#619131; Package dpkg. (Thu, 24 Mar 2011 07:57:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Joerg Jaspert <joerg@ganneff.de>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 24 Mar 2011 07:57:07 GMT) Full text and rfc822 format available.

Message #27 received at 619131@bugs.debian.org (full text, mbox):

From: Joerg Jaspert <joerg@ganneff.de>
To: Raphael Hertzog <hertzog@debian.org>
Cc: 619131@bugs.debian.org, Guillem Jover <guillem@debian.org>
Subject: Re: Bug#619131: dpkg: new field in .dsc
Date: Thu, 24 Mar 2011 08:47:08 +0100
>> The argument of saving something in terms of sizes is not much
>> convincing to me, looking at the usual size of stuff we are dealing with
>> anyways. A few more lines of text dont seem to matter, imo. It is also
>> easier to work with them in shell scripts.
> The size of the individual .dsc is not anything I would be worried of
> but the cumulated size in Sources.gz is more of a concern. Obviously
> we might decide to not store this field there but that means modifying
> all software that can generate those.

The one where it *really* matters size wise is the Debian archive.
And I dont think it would need to write those entries out.

>> Oh, and just before I hit send:
>> <buxy> Ganneff: my current preference for the field name goes to "Categorization"
> I think it's going to be "Package-List" because Package-Set could be
> slightly confusing with the terminology we use internally for a set of MultiArch:
> same package.

Fine.

>> Neither of these are truly possible w/o breaking current assumptions.
>> There's no guarantee at all that the binary stanzas in debian/control
>> correspond with what will be shipped in the .changes file. The only
>> stanza that is guaranteed to be constant is the source one.

>> In addition it's currently supported to ship less packages than the
>> ones listed in debian/control, even if dpkg-genchanges will warn about
>> it. And besides changing or adding new binary stanzas to debian/control,
>> adding new files not present in debian/control has been supported for a
>> long time via dpkg-distaddfile.

> Note that the field is going to be in the .dsc not in the .changes. Note
> also that automatically modifying debian/control at build time has been
> frowned upon for a long time (and forbidden by the ftpmasters in their
> review). When debian/control is automatically generated, it's always done
> manually before the source build so that the source contains a matching
> list of packages in debian/control.

> In practice, dpkg-distaddfile is mainly used manually to upload
> non-packages (debian-installer images, debtags db, etc.).

> So I think it's ok to go ahead with the assumption that all packages that
> we care about are listed in debian/control.

Worst case, if there *IS* an entry that wasnt listed in Packages-List:,
it will just trigger an extra NEW run. It won't die.

And if there is one too much when we add the overrides, that is even
less of a concern - unused overrides are cleaned out regularly.

>> I'm not sure how you are currently handling the NEW processing
>> regarding the overrides, but from what I've seen I've got the
>> impression package sections and priorities are not usually overriden
>> on that stage (as they used to be)? If that's the case then the
>> archive software could as well initialize the overrides automatically
>> with the entries from the binary packages in the .changes file.
> AFAIK any package which does not appear in the overrides file is
> considered NEW and triggers the corresponding review.

> Thus they want to set the overrides for all the possible binaries as soon
> as they have reviewed the source package so that each linux-2.6 upload
> does not trigger NEW but only the first one with sources. They do not have
> all the .debs at this point so can't extract the priorities.

linux-2.6 is only an example, even if its the biggest customer of it, yes.

> They have a list of binary packages though and could add the entries with
> a special value which means "auto-set with the first value seen for this
> package". Ganneff, have you considered doing this?

First, to counter Guillem: No, we are changing overrides, even if he
might not have seen it. So no, we are not going to blindly take
them. And no, an "autoset" one as I think its meant doesnt sound like a
good option.

-- 
bye, Joerg
Free beer is something that I am never going to drink and free speech is
something that people are never going to be allowed to. ;)




Added tag(s) pending. Request was from Raphaël Hertzog <hertzog@debian.org> to control@bugs.debian.org. (Thu, 24 Mar 2011 14:06:12 GMT) Full text and rfc822 format available.

Message sent on to Joerg Jaspert <joerg@ganneff.de>:
Bug#619131. (Thu, 24 Mar 2011 14:06:15 GMT) Full text and rfc822 format available.

Message #32 received at 619131-submitter@bugs.debian.org (full text, mbox):

From: Raphaël Hertzog <hertzog@debian.org>
To: 619131-submitter@bugs.debian.org
Subject: Bug#619131 marked as pending
Date: Thu, 24 Mar 2011 14:01:26 +0000
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 <hertzog@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




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#619131; Package dpkg. (Thu, 24 Mar 2011 14:39:10 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Bernhard R. Link" <brlink@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 24 Mar 2011 14:39:10 GMT) Full text and rfc822 format available.

Message #37 received at 619131@bugs.debian.org (full text, mbox):

From: "Bernhard R. Link" <brlink@debian.org>
To: debian-policy@lists.debian.org
Cc: Raphael Hertzog <hertzog@debian.org>, 619131@bugs.debian.org
Subject: Re: New field Package-List in .dsc
Date: Thu, 24 Mar 2011 15:37:42 +0100
* Raphael Hertzog <hertzog@debian.org> [110324 15:14]:
> ftpmasters requested a new field in the .dsc files to ease their work.
> I just implemented it and it will be part of dpkg 1.16.0.
>
> This has been done on short notice so I wanted to inform policy people
> so that you can review the discussions and the design in case anyone has
> objections/suggestions before it's in wide-spread usage:
> http://bugs.debian.org/619131

Do I understand this correction correctly that "dpkg-source -b" will
generate that when generating a source package (or will this need any
changing in scripts calling dpkg-source -b ?)

This is put in the .dsc but everything that makes a Sources out of it
will need to remove it again (or have an unnecessary large Source file)?

If it is only used to give hints to dak, what is the reason that this is
in .dsc and not in .changes? (Or perhaps even only in .changes that also
include a source package).

> It looks like this:
>
> Package-List:
>  src:dpkg admin required
>  dpkg admin required
>  dpkg-dev utils optional
>  libdpkg-dev libdevel optional
>  libdpkg-perl perl optional
>  udeb:dselect admin optional
>
> (Here I just marked dselect as being an udeb for a test...)
>
> The purpose is so that they can setup the overrides for all possible binary
> packages as soon as they have reviewed the source package (i.e. and avoid NEW
> for subsequent binary uploads introducing binary packages that they have not
> yet seen).

If it really is in the .dsc files then it would be nice if it also could
include the Architecture: of those packages. That would make it easier
for things like reprepro to decide if there might be some binary package
missing. (Or for other forms of poor-man's stateless wanna-build stuff).

	Bernhard R. Link




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#619131; Package dpkg. (Thu, 24 Mar 2011 15:21:13 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 24 Mar 2011 15:21:13 GMT) Full text and rfc822 format available.

Message #42 received at 619131@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: debian-policy@lists.debian.org, 619131@bugs.debian.org
Subject: Re: Bug#619131: New field Package-List in .dsc
Date: Thu, 24 Mar 2011 16:20:01 +0100
Hi,

On Thu, 24 Mar 2011, Bernhard R. Link wrote:
> Do I understand this correction correctly that "dpkg-source -b" will
> generate that when generating a source package.

Yes.

> This is put in the .dsc but everything that makes a Sources out of it
> will need to remove it again (or have an unnecessary large Source file)?

Yes (but unnecessary large is somewhat overdone).

> If it is only used to give hints to dak, what is the reason that this is
> in .dsc and not in .changes? (Or perhaps even only in .changes that also
> include a source package).

Because this is information about the source package and not about the
upload.

I discarded the .changes because we would duplicate the information in all
.changes while it's not needed. Putting it only in .changes containing a
source might be doable but that has never been done before and I'm not
sure it's a good idea to start with ("fields appearing depending on
whether a source is uploaded or not").

> If it really is in the .dsc files then it would be nice if it also could
> include the Architecture: of those packages. That would make it easier
> for things like reprepro to decide if there might be some binary package
> missing. (Or for other forms of poor-man's stateless wanna-build stuff).

The architecture is not a single value, but rather a list of values (in the
source package). It might be doable to put that list at the end of
the line but it doesn't feel quite right. What do others think?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#619131; Package dpkg. (Thu, 24 Mar 2011 18:03:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 24 Mar 2011 18:03:03 GMT) Full text and rfc822 format available.

Message #47 received at 619131@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: debian-policy@lists.debian.org, 619131@bugs.debian.org
Subject: Re: Bug#619131: New field Package-List in .dsc
Date: Thu, 24 Mar 2011 11:00:45 -0700
Raphael Hertzog <hertzog@debian.org> writes:
> On Thu, 24 Mar 2011, Bernhard R. Link wrote:

>> If it really is in the .dsc files then it would be nice if it also
>> could include the Architecture: of those packages. That would make it
>> easier for things like reprepro to decide if there might be some binary
>> package missing. (Or for other forms of poor-man's stateless
>> wanna-build stuff).

> The architecture is not a single value, but rather a list of values (in
> the source package). It might be doable to put that list at the end of
> the line but it doesn't feel quite right. What do others think?

The missing architecture was my immediate thought as well, since for a
moment I thought ftp-master might need it, but then I realized that the
override settings are arch: all.  So I'm ambivalent.

I will mention that if you wanted to add the architecture, you could just
s/ +/,/g on the architecture list and then you'd get something that should
be reasonably easy to parse and would still use spaces to separate from
other fields, since the architecture list isn't too complex in syntax
other than being a list.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#619131; Package dpkg. (Thu, 24 Mar 2011 18:42:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Bernhard R. Link" <brlink@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 24 Mar 2011 18:42:03 GMT) Full text and rfc822 format available.

Message #52 received at 619131@bugs.debian.org (full text, mbox):

From: "Bernhard R. Link" <brlink@debian.org>
To: debian-policy@lists.debian.org
Cc: Raphael Hertzog <hertzog@debian.org>, 619131@bugs.debian.org
Subject: Re: Bug#619131: New field Package-List in .dsc
Date: Thu, 24 Mar 2011 19:38:18 +0100
* Raphael Hertzog <hertzog@debian.org> [110324 16:20]:
> > If it is only used to give hints to dak, what is the reason that this is
> > in .dsc and not in .changes? (Or perhaps even only in .changes that also
> > include a source package).
>
> Because this is information about the source package and not about the
> upload.

For example until today .dsc files did not contain information about the
Section and Priority of the source package[1]. That information was only
in the .changes file (I guess because it was mostly a hint to
ftp-masters, just like this information is now, too).

> I discarded the .changes because we would duplicate the information in all
> .changes while it's not needed. Putting it only in .changes containing a
> source might be doable but that has never been done before and I'm not
> sure it's a good idea to start with ("fields appearing depending on
> whether a source is uploaded or not").

I'd rather see this as "fields only there if the upload has something to
say in this regard".

	Bernhard R. Link

[1] Which is something I'm very happy if it changes[2]. Though having it as
"Package-List:\n src:<srcname>" is a bit more complicated than just
having Section and Priority fields.
[2] Currently reprepro can guess it by things like parsing a .diff file,
which is code I'd be very happy if I could remove it in some years.




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#619131; Package dpkg. (Sat, 26 Mar 2011 08:57:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sat, 26 Mar 2011 08:57:02 GMT) Full text and rfc822 format available.

Message #57 received at 619131@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Russ Allbery <rra@debian.org>, debian-policy@lists.debian.org
Cc: 619131@bugs.debian.org
Subject: Re: Bug#619131: New field Package-List in .dsc
Date: Sat, 26 Mar 2011 09:52:38 +0100
On Thu, 24 Mar 2011, Russ Allbery wrote:
> The missing architecture was my immediate thought as well, since for a
> moment I thought ftp-master might need it, but then I realized that the
> override settings are arch: all.  So I'm ambivalent.

But apparently the wanna-build team would like to have this information as
well (to know which source packages build arch: all packages). So I'm
going to add it and I'll follow you advice of replacing spaces by
commas. That way we still have the possibility to add supplementary
columns in the future if needed.

On Fri, 25 Mar 2011, Bastian Blank wrote:
> On Thu, Mar 24, 2011 at 03:14:00PM +0100, Raphael Hertzog wrote:
> > It looks like this:
> > Package-List: 
> >  src:dpkg admin required
> 
> Is there a reason for not listing the type explicit for every entry?
> Something like this:
>  dpkg source admin required
>  dpkg deb admin required
>  dselect udeb admin optional

No, there was none. I also find this clearer and more scriptable. So
adopted. Thanks.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#619131; Package dpkg. (Sat, 26 Mar 2011 09:24:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bastian Blank <waldi@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sat, 26 Mar 2011 09:24:03 GMT) Full text and rfc822 format available.

Message #62 received at 619131@bugs.debian.org (full text, mbox):

From: Bastian Blank <waldi@debian.org>
To: debian-policy@lists.debian.org
Cc: Raphael Hertzog <hertzog@debian.org>, Russ Allbery <rra@debian.org>, 619131@bugs.debian.org
Subject: Re: Bug#619131: New field Package-List in .dsc
Date: Sat, 26 Mar 2011 10:20:19 +0100
On Sat, Mar 26, 2011 at 09:52:38AM +0100, Raphael Hertzog wrote:
> On Thu, 24 Mar 2011, Russ Allbery wrote:
> > The missing architecture was my immediate thought as well, since for a
> > moment I thought ftp-master might need it, but then I realized that the
> > override settings are arch: all.  So I'm ambivalent.
> But apparently the wanna-build team would like to have this information as
> well (to know which source packages build arch: all packages). So I'm
> going to add it and I'll follow you advice of replacing spaces by
> commas. That way we still have the possibility to add supplementary
> columns in the future if needed.

On second thought, I think it is time to make this a key-value list
instead of bare values. Then we can add or remove values without
disrupting other users of the infos. Also a vendor may explicitely add
new values if they think they need it.

Bastian

-- 
Those who hate and fight must stop themselves -- otherwise it is not stopped.
		-- Spock, "Day of the Dove", stardate unknown




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#619131; Package dpkg. (Sat, 26 Mar 2011 13:48:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sat, 26 Mar 2011 13:48:03 GMT) Full text and rfc822 format available.

Message #67 received at 619131@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: debian-policy@lists.debian.org, Russ Allbery <rra@debian.org>, 619131@bugs.debian.org
Subject: Re: New field Package-List in .dsc
Date: Sat, 26 Mar 2011 14:45:20 +0100
On Sat, 26 Mar 2011, Bastian Blank wrote:
> On Thu, Mar 24, 2011 at 04:25:46PM +0100, Raphael Hertzog wrote:
> >                                                    First line is always
> > the source entry.
> 
> Do you want this constraint part of the definition or a implementation
> detail?

I don't really care. I think it's cleaner to always have it first but
I don't think it matters much.

On Sat, 26 Mar 2011, Bastian Blank wrote:
> On Sat, Mar 26, 2011 at 09:52:38AM +0100, Raphael Hertzog wrote:
> > But apparently the wanna-build team would like to have this information as
> > well (to know which source packages build arch: all packages). So I'm
> > going to add it and I'll follow you advice of replacing spaces by
> > commas. That way we still have the possibility to add supplementary
> > columns in the future if needed.
> 
> On second thought, I think it is time to make this a key-value list
> instead of bare values. Then we can add or remove values without
> disrupting other users of the infos. Also a vendor may explicitely add
> new values if they think they need it.

That would be overkill. Vendor already have the option to add
supplementary fields[1] so I don't see whey they would have to also be able
add values in that field in particular.

Cheers,

[1] And Ubuntu uses it for Launchpad-Bugs-Fixed in .changes.
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#619131; Package dpkg. (Fri, 01 Apr 2011 17:18:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Fri, 01 Apr 2011 17:18:05 GMT) Full text and rfc822 format available.

Message #72 received at 619131@bugs.debian.org (full text, mbox):

From: Guillem Jover <guillem@debian.org>
To: Raphaël Hertzog <hertzog@debian.org>, 619131@bugs.debian.org
Subject: Re: Bug#619131: marked as pending
Date: Fri, 1 Apr 2011 19:10:10 +0200
[Message part 1 (text/plain, inline)]
Hi!

On Thu, 2011-03-24 at 14:01:26 +0000, Raphaël Hertzog wrote:
> commit 014672432452a6f6a18c44e733fece7938685370
> Author: Raphaël Hertzog <hertzog@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
[dpkg-diable-dsc-pkg-list.patch (text/x-diff, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#619131; Package dpkg. (Fri, 01 Apr 2011 19:39:16 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Fri, 01 Apr 2011 19:39:16 GMT) Full text and rfc822 format available.

Message #77 received at 619131@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Guillem Jover <guillem@debian.org>
Cc: 619131@bugs.debian.org
Subject: Re: Bug#619131: marked as pending
Date: Fri, 1 Apr 2011 21:30:20 +0200
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)




Removed tag(s) pending. Request was from Raphaël Hertzog <hertzog@debian.org> to control@bugs.debian.org. (Fri, 01 Apr 2011 20:06:04 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#619131; Package dpkg. (Thu, 07 Apr 2011 20:30:29 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 07 Apr 2011 20:30:29 GMT) Full text and rfc822 format available.

Message #84 received at 619131@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Guillem Jover <guillem@debian.org>
Cc: 619131@bugs.debian.org, pkern@debian.org
Subject: Package-List field
Date: Thu, 7 Apr 2011 22:29:29 +0200
Hi,

On Fri, 01 Apr 2011, Raphael Hertzog wrote:
> But ok, we can take some more time to discuss and push it for 1.16.1.

So what should we change to re-enable the field?

Given the concerns you raised, we can at least drop the source entry from
Package-List.

Maybe introduce Priority/Section as new fields in the .dsc although
nothing is making use of that information and while I was confortable
adding it within an existing field, I'm not convinced it's important
enough to add 2 new fields.

Concerning the architecture information, I'm not attached to keeping
it in the field, but I believe exporting the architecture information
would be much more useful than the section/priority (which is mainly
interesting for ftpmasters but has few users outside of them). So my
vote is rather to keep it in the field. But I'd rather drop it if it can
help resolve the discussion sooner, it can always be added later on... we
must just define the field as being extendable and that parsers must
just ignore supplementary columns.

Whatever the decision on the arch column in Package-List, we can still fix
the "Architecture" field to include the missing "all" which is wrongly
hidden by the "any" (and fix policy accordingly).

I have already responded to the concerns of Priority/Section being
updated at build time and I argue that it's not important enough to
extend the syntax of that field. It still represents the default value
of section/priority for most architectures. If such an inconsistency ever
arises, it will concern a very small number of packages and the invalid
field will only lead to some override disparities message which are easily
fixed by the ftpmasters (provided they have extended the overrides to be
per-arch).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)




Bug reassigned from package 'dpkg' to 'dpkg-dev'. Request was from Guillem Jover <guillem@debian.org> to control@bugs.debian.org. (Thu, 14 Apr 2011 05:33:07 GMT) Full text and rfc822 format available.

Bug No longer marked as found in versions dpkg/1.15.8.10. Request was from Guillem Jover <guillem@debian.org> to control@bugs.debian.org. (Thu, 14 Apr 2011 05:33:07 GMT) Full text and rfc822 format available.

Changed Bug title to 'dpkg-source: Add more binary package information to .dsc' from 'dpkg: new field in .dsc' Request was from Guillem Jover <guillem@debian.org> to control@bugs.debian.org. (Thu, 14 Apr 2011 05:33:08 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#619131; Package dpkg-dev. (Wed, 20 Apr 2011 22:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Wed, 20 Apr 2011 22:33:03 GMT) Full text and rfc822 format available.

Message #95 received at 619131@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Guillem Jover <guillem@debian.org>
Cc: 619131@bugs.debian.org
Subject: Re: Bug#619131: Package-List field
Date: Thu, 21 Apr 2011 00:28:41 +0200
Hi Guillem,

can you reply to my mail below?

I don't want this request to sit there for months. We should be able to
take such small design decisions in reasonable timeframes.

Cheers,

On Thu, 07 Apr 2011, Raphael Hertzog wrote:
> Hi,
> 
> On Fri, 01 Apr 2011, Raphael Hertzog wrote:
> > But ok, we can take some more time to discuss and push it for 1.16.1.
> 
> So what should we change to re-enable the field?
> 
> Given the concerns you raised, we can at least drop the source entry from
> Package-List.
> 
> Maybe introduce Priority/Section as new fields in the .dsc although
> nothing is making use of that information and while I was confortable
> adding it within an existing field, I'm not convinced it's important
> enough to add 2 new fields.
> 
> Concerning the architecture information, I'm not attached to keeping
> it in the field, but I believe exporting the architecture information
> would be much more useful than the section/priority (which is mainly
> interesting for ftpmasters but has few users outside of them). So my
> vote is rather to keep it in the field. But I'd rather drop it if it can
> help resolve the discussion sooner, it can always be added later on... we
> must just define the field as being extendable and that parsers must
> just ignore supplementary columns.
> 
> Whatever the decision on the arch column in Package-List, we can still fix
> the "Architecture" field to include the missing "all" which is wrongly
> hidden by the "any" (and fix policy accordingly).
> 
> I have already responded to the concerns of Priority/Section being
> updated at build time and I argue that it's not important enough to
> extend the syntax of that field. It still represents the default value
> of section/priority for most architectures. If such an inconsistency ever
> arises, it will concern a very small number of packages and the invalid
> field will only lead to some override disparities message which are easily
> fixed by the ftpmasters (provided they have extended the overrides to be
> per-arch).
> 
> Cheers,
> -- 
> Raphaël Hertzog ◈ Debian Developer
> 
> Follow my Debian News ▶ http://RaphaelHertzog.com (English)
>                       ▶ http://RaphaelHertzog.fr (Français)
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#619131; Package dpkg-dev. (Sun, 15 May 2011 07:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sun, 15 May 2011 07:27:03 GMT) Full text and rfc822 format available.

Message #100 received at 619131@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Guillem Jover <guillem@debian.org>
Cc: 619131@bugs.debian.org
Subject: Re: Bug#619131: Package-List field
Date: Sun, 15 May 2011 09:22:48 +0200
Hi,

Ping again. Without any answer, at some point I'll just go ahead with the
compromise that I suggested.

Cheers,

On Thu, 21 Apr 2011, Raphael Hertzog wrote:
> Hi Guillem,
> 
> can you reply to my mail below?
> 
> I don't want this request to sit there for months. We should be able to
> take such small design decisions in reasonable timeframes.
> 
> Cheers,
> 
> On Thu, 07 Apr 2011, Raphael Hertzog wrote:
> > Hi,
> > 
> > On Fri, 01 Apr 2011, Raphael Hertzog wrote:
> > > But ok, we can take some more time to discuss and push it for 1.16.1.
> > 
> > So what should we change to re-enable the field?
> > 
> > Given the concerns you raised, we can at least drop the source entry from
> > Package-List.
> > 
> > Maybe introduce Priority/Section as new fields in the .dsc although
> > nothing is making use of that information and while I was confortable
> > adding it within an existing field, I'm not convinced it's important
> > enough to add 2 new fields.
> > 
> > Concerning the architecture information, I'm not attached to keeping
> > it in the field, but I believe exporting the architecture information
> > would be much more useful than the section/priority (which is mainly
> > interesting for ftpmasters but has few users outside of them). So my
> > vote is rather to keep it in the field. But I'd rather drop it if it can
> > help resolve the discussion sooner, it can always be added later on... we
> > must just define the field as being extendable and that parsers must
> > just ignore supplementary columns.
> > 
> > Whatever the decision on the arch column in Package-List, we can still fix
> > the "Architecture" field to include the missing "all" which is wrongly
> > hidden by the "any" (and fix policy accordingly).
> > 
> > I have already responded to the concerns of Priority/Section being
> > updated at build time and I argue that it's not important enough to
> > extend the syntax of that field. It still represents the default value
> > of section/priority for most architectures. If such an inconsistency ever
> > arises, it will concern a very small number of packages and the invalid
> > field will only lead to some override disparities message which are easily
> > fixed by the ftpmasters (provided they have extended the overrides to be
> > per-arch).
> > 
> > Cheers,
> > -- 
> > Raphaël Hertzog ◈ Debian Developer
> > 
> > Follow my Debian News ▶ http://RaphaelHertzog.com (English)
> >                       ▶ http://RaphaelHertzog.fr (Français)
> -- 
> Raphaël Hertzog ◈ Debian Developer
> 
> Follow my Debian News ▶ http://RaphaelHertzog.com (English)
>                       ▶ http://RaphaelHertzog.fr (Français)
> 
> 
> 

-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)




Added tag(s) pending. Request was from Raphaël Hertzog <hertzog@debian.org> to control@bugs.debian.org. (Sat, 28 May 2011 13:21:25 GMT) Full text and rfc822 format available.

Message sent on to Joerg Jaspert <joerg@ganneff.de>:
Bug#619131. (Sat, 28 May 2011 13:21:57 GMT) Full text and rfc822 format available.

Message #105 received at 619131-submitter@bugs.debian.org (full text, mbox):

From: Raphaël Hertzog <hertzog@debian.org>
To: 619131-submitter@bugs.debian.org
Subject: Bug#619131 marked as pending
Date: Sat, 28 May 2011 13:18:31 +0000
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 <hertzog@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




Reply sent to Guillem Jover <guillem@debian.org>:
You have taken responsibility. (Fri, 23 Sep 2011 05:21:50 GMT) Full text and rfc822 format available.

Notification sent to Joerg Jaspert <joerg@ganneff.de>:
Bug acknowledged by developer. (Fri, 23 Sep 2011 05:21:51 GMT) Full text and rfc822 format available.

Message #110 received at 619131-close@bugs.debian.org (full text, mbox):

From: Guillem Jover <guillem@debian.org>
To: 619131-close@bugs.debian.org
Subject: Bug#619131: fixed in dpkg 1.16.1
Date: Fri, 23 Sep 2011 05:17:20 +0000
Source: dpkg
Source-Version: 1.16.1

We believe that the bug you reported is fixed in the latest version of
dpkg, which is due to be installed in the Debian FTP archive:

dpkg-dev_1.16.1_all.deb
  to main/d/dpkg/dpkg-dev_1.16.1_all.deb
dpkg_1.16.1.dsc
  to main/d/dpkg/dpkg_1.16.1.dsc
dpkg_1.16.1.tar.bz2
  to main/d/dpkg/dpkg_1.16.1.tar.bz2
dpkg_1.16.1_amd64.deb
  to main/d/dpkg/dpkg_1.16.1_amd64.deb
dselect_1.16.1_amd64.deb
  to main/d/dpkg/dselect_1.16.1_amd64.deb
libdpkg-dev_1.16.1_amd64.deb
  to main/d/dpkg/libdpkg-dev_1.16.1_amd64.deb
libdpkg-perl_1.16.1_all.deb
  to main/d/dpkg/libdpkg-perl_1.16.1_all.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 619131@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Guillem Jover <guillem@debian.org> (supplier of updated dpkg package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Fri, 23 Sep 2011 06:00:11 +0200
Source: dpkg
Binary: libdpkg-dev dpkg dpkg-dev libdpkg-perl dselect
Architecture: source amd64 all
Version: 1.16.1
Distribution: unstable
Urgency: low
Maintainer: Dpkg Developers <debian-dpkg@lists.debian.org>
Changed-By: Guillem Jover <guillem@debian.org>
Description: 
 dpkg       - Debian package management system
 dpkg-dev   - Debian package development tools
 dselect    - Debian package management front-end
 libdpkg-dev - Debian package management static library
 libdpkg-perl - Dpkg perl modules
Closes: 147583 231089 245322 293280 308082 454694 489771 525160 526774 552123 560070 560251 603435 604241 606839 608260 610940 615899 616609 619131 620312 620490 620520 621066 622094 626684 627462 628055 628726 629582 630533 630996 631435 631439 631494 631547 631757 631808 632168 632937 633539 633627 634510 634961 635467 635683 636700 637096 637564 638291 639229 639997 640198 640298 641834
Changes: 
 dpkg (1.16.1) unstable; urgency=low
 .
   [ Raphaël Hertzog ]
   * Dpkg::Deps: Implement new "reset" method and bump module version to 1.01
     due to this.
   * Improved description of --search in dpkg-query(1). Closes: #621066
     Thanks to Lars Buitinck <larsmans@gmail.com> for the patch.
   * Let update-alternatives fsync() its administrative files before
     moving them in place to avoid empty files with some filesystems.
     LP: #344019
   * Tighten the regexp used by dpkg-source to ignore the .pc directory of
     quilt. Thanks to Mike Hommey for noticing the problem.
   * Change behaviour of dpkg-source's --extend-diff-ignore to also
     extend the current diff-ignore if it has already been set.
   * Fix dependency checking code to consider a dependency on a virtual
     package provided by a package in triggers-pending status as satisfied.
   * Do not fail when encountering a pre-dependency in triggers-awaited state,
     instead process the awaited triggers. Closes: #526774
   * "any" no longer hides "all" in the Architecture field of a .dsc.
   * Fix dpkg --remove to really remove the triggers from the various
     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
   * Re-enable 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
   * Add the extraction part of Dpkg::Source::Package to the supported API.
     Useful to extract source packages without having to depend on dpkg-source
     (and hence dpkg-dev).
   * Add the Dpkg::Vendor module to the supported API. Useful for lintian
     when dpkg-dev is absent.
   * Check presence of required parameters in dpkg-vendor. Closes: #628726
     Thanks to Niels Thykier <niels@thykier.net> for the patch.
   * Avoid a Perl warning in dpkg-buildflags when HOME is not set.
     Closes: #635467
   * dpkg-source can now also use debian/source/local-patch-header (that is not
     included in the generated source package) instead of
     debian/source/patch-header. Closes: #629582
   * Changed dpkg-source --after-build to automatically unapply patches that it
     has applied during --before-build.
   * Fix two possible causes for the assertion failure "pigp->trigpend_head".
     LP: #798793, #424358 Closes: #560251
   * Use "special" instead of "particular" to qualify the "3.0 (custom)" format
     in dpkg-source(1). Closes: #631435
   * Add some supplementary checks to ensure debian/control has the required
     fields. Closes: #631439
   * dpkg-gensymbols(1): document syntax of comments. Closes: #630996
   * Allow empty lines in symbols files to better delimit multiple libraries.
     Thanks to Cyril Brulebois <kibi@debian.org> for the patch.
   * dpkg: if "prerm upgrade" fails when downgrading, do not try to run
     "prerm failed-upgrade" with the prerm of the oldest prerm, it can't work
     around a bug of a newer prerm anyway.
   * dpkg: support new "interest-noawait" and "activate-noawait" trigger
     directives.
   * dpkg-buildflags(1): make it clear that DEB_*_(SET|APPEND) environment
     variables are meant for users and should not be used by packages.
   * update-alternatives: do not allow to reuse a slave link in another
     slave alternative. Closes: #631547
   * Improve dpkg-source's logic to identify ignored files. Closes: #632168
   * Fix a small typo in dpkg-source(1). Closes: #632937
   * Reword the description of dpkg-source --before-build and --after-build
     to be clearer. Closes: #608260
   * dpkg-buildpackage no longer exports the compiler flags. Closes: #560070
     Packages must directly call dpkg-buildflags to retrieve them.
   * dpkg-buildflags supports a prepend command to modify the build
     flags. Particularly useful for package maintainers who don't want
     their supplementary flags to take precedence over user submitted
     flags.
   * Add new --dump action to dpkg-buildflags and make it the default action.
     Closes: #603435
   * dpkg-mergechangelogs now checks the return value of the close() call.
     Thanks to Niels Thykier <niels@thykier.net> for the patch. Closes: #633539
   * Similar changes to dpkg-shlibdeps and dpkg-gencontrol, also by Niels.
   * Fix update-alternatives to not remove a real file when dropping a
     symlink for a slave that's not provided by the new current choice.
     Closes: #633627
   * Improve dpkg-source's error message complaining about the lack
     of the upstream tarball. Closes: #634510
   * Add some common makefile snippets for use in rules files in
     /usr/share/dpkg/: default.mk, architecture.mk, buildflags.mk, pkg-info.mk,
     vendor.mk Closes: #606839
   * Fix the dpkg-divert test-suite to also skip test that would fail if run
     under root. Closes: #634961
   * Change merge conflict separators created by dpkg-mergechangelogs to match
     the usual norm of being composed of 7 characters. LP: #815700
   * With source format 2.0 and 3.0 (quilt), dpkg-source now fails by default
     when upstream changes have not been recorded in a quilt patch. The new
     --commit operation can be used to properly record the changes before-hand.
     LP: #797839
     And it fails before installing the automatic patch in debian/patches/
     Closes: #615899
   * dpkg-buildflags now supports "--export=configure" to output compilation
     flags on a single line with double quotes as delimiter of the various
     values. It also uses DEB_<flag>_MAINT_<op> to let the maintainer
     extend the build flags to use. Last but not least, it can now also strip
     options from the returned build flags.
   * Fix possible segfault of dpkg in findbreakcycle(). LP: #733414
   * dpkg-source now properly cleans up the temporary tarball generated for
     native formats in case of unexpected interruption. Closes: #631494
   * Fix simplification logic of union dependencies. Closes: #637564
   * Fix dpkg's handling of a hardlink pointing to a conffile. Closes: #638291
   * Add example of extend-diff-ignore's usage in dpkg-source(1).
     Closes: #640198
   * dpkg-buildflags now returns hardening flags by default. Closes: #489771
     They can be individually enabled/disabled via DEB_BUILD_MAINT_OPTIONS,
     see dpkg-buildflags(1). Thanks to Kees Cook for his help.
 .
   [ Guillem Jover ]
   * Install deb-src-control(5) man pages in dpkg-dev. Closes: #620520
   * Add ‘.gitmodules’ to the default dpkg-source ignore lists. Closes: #620490
   * Document in dpkg-query(1) man page that on --listfiles each list of
     files per package name is separated by a blank line. Same goes for
     --status and --print-avail.
   * Use execvp(3) unconditionally in command_exec(). Making the call always
     fallback to use the system shell in case of error, such as with empty
     maintainer scripts. Thanks to Jonathan Nieder <jrnieder@gmail.com>.
     Closes: #622094
   * Improve deb-split(5) format description by splitting debian-split
     member contents into a list.
   * Switch to debhelper compatibility level 7.
     - Use dh_prep instead of deprecated “dh_clean -k”.
   * Bump Standards-Version to 3.9.2 (no changes needed).
   * Generate filenames following current conventions on “dpkg-split --join”,
     by including the architecture in the debian-split member of a split
     package and using underscores to separate filename parts.
   * Support conffiles with spaces when diffing them. Closes: #147583
   * Allow installing packages with bogus versions with new
     --force-bad-version.
   * Do not fail when unpacking a diverted hardlink. Closes: #245322
     Based on a patch by Christopher Baines <cbaines8@gmail.com>.
   * Document in dpkg-deb(1) that --fsys-tarfile will always process the
     input archive sequentially. Closes: #616609
   * Remove long non-functional --new and --old dpkg-deb option handling
     from dpkg which were being treated as dpkg commands.
   * Remove reference to --nocheck dpkg-deb option from dpkg man page as
     the latter does not pass it to the former.
   * Clarify the current dpkg behaviour when running the dpkg-deb and
     dpkg-query back-ends, of not passing through back-end specific options
     when running them from dpkg. Closes: #610940
   * Use “unselected” as an adjective in dpkg output messages instead of
     “deselected”. Closes: #231089
   * Clarify exit status in dpkg-split and start-stop-daemon --help output.
   * Clarify “EXIT STATUS” section in man pages by using a table.
   * Add a --status command to start-stop-daemon returning LSB Init Script
     status action exit codes.
   * Add start-stop-daemon process name kernel limits for Solaris, NetBSD,
     OpenBSD, FreeBSD and Darwin.
   * On package removal, keep only directories actually containing conffiles,
     and not directories just matching the substring in the conffile or the
     directory itself. Thanks to Ondřej Surý <ondrej@debian.org>.
   * On purge correctly remove symlinks acting as directories, when they are
     not being used by any other package's files.
   * Do not lose track of parent directories on removal so that they can
     be properly cleaned up on purge if not used by any other package.
     Based on a patch by Ondřej Surý <ondrej@debian.org>. Closes: #454694
   * Add ‘.hgsigs’ to the default dpkg-source ignore lists.
     Based on a patch by Jakub Wilk <jwilk@debian.org>. Closes: #627462
   * Do not allow blank lines in field values. Closes: #308082
   * Do not warn on missing architecture on packages in config-files state,
     but then make sure the architecture field is usable. Closes: #604241
   * Run du with --apparent-size when generating the Installed-Size field in
     dpkg-gencontrol to get consistent results independent of build system.
     Thanks to Ludovic Brenta <ludovic@ludovic-brenta.org>. Closes: #630533
   * Do not fail to unpack shared directories missing on the file system
     from packages being replaced by other packages. Closes: #631808
   * Do not require programs to define thisname, provide two new functions
     to handle the program name (dpkg_set_progname and dpkg_get_progname).
     Closes: #631757
   * Man pages cleanup:
     - Rename “USAGE” dselect(1) section to “ACTIONS” and clarify they can
       be performed interactively or from command line.
     - Add missing built-in methods to dselect(1).
     - Add missing escaping to field dashes in deb-control(5).
     - Use dashes instead of underscores for variable text.
     - Clarify that several front-end fields are not dselect specific in
       dpkg-query(1).
     - Use [option...] instead of [options] and friends.
     - Use italics or bold instead of surrounding the text with <>.
     - Correctly format text with bold and italics.
     - Use minus signs and hyphens consistently in man pages.
     - Fix reference to /etc/dpkg/dselect.cfg.d instead of dpkg.cfg.d in
       dselect(1).
     - Add missing optional group|gid --chuid argument in start-stop-daemon(8).
   * Refer to Sources and Packages files as part of a repository instead of
     as being of exclusive use or owned by APT, which has never been the case.
   * Unify somewhat dpkg-maintscript-helper --help output with other commands.
   * Add build-indep and build-arch targets as aliases for build in
     debian/rules.
   * Use the perl interpreter found by configure to call dpkg-architecture.pl
     in the m4 DPKG_ARCHITECTURE macro.
   * Add new --verbose option to dpkg-deb and change --extract to honour it.
     Closes: #293280
   * Add new --raw-extract option to dpkg-deb combining --control and
     --extract. Closes: #552123
   * Defer hardlink renames so that there's never a point were the new
     file contents are accessible from the final path before they have
     been fsync()ed and cannot be executed causing ETXTBSY when trying
     to open the to be installed paths for writing.
     Thanks to Jonathan Nieder <jrnieder@gmail.com>. Closes: #635683
   * Clarify the default dpkg-deb compression-levels on the man page.
   * Clarify dpkg --update-avail usage error message. Closes: #628055
   * Change Dpkg::Compression default values depending on the compressor
     used, and as such dpkg-source inherits this functionality.
     Prompted by Timo Juhani Lindfors <timo.lindfors@iki.fi>.
   * Print an actual error or warning message instead of assert()ing on
     readlink()/stat() size discrepancies. Closes: #639229
   * Update alternative links only if they change. This allows for a
     read-only file system and a writable database. Closes: #636700
     Based on a patch by Salvatore Bonaccorso <carnil@debian.org>.
   * Fix double “error:” string in dpkg missing PATH error output.
     Closes: #639997
   * Do not warn on strange timestamps when unpacking with dpkg-deb.
     Closes: #640298
   * Reduce dpkg-trigger binary size by refactoring libdpkg modules so that
     it does not end up pulling triglib.
   * Reduce dpkg-deb binary size by refectoring libdpkg modules so that it
     does not end up pulling triglib.
   * Do not fail on --compare-version when generating parse warnings.
     Existing packages with invalid versions should not fail on their
     maintainer scripts due to that.
   * Use the user name (instead of the user id) when setting the supplementary
     groups in start-stop-daemon. Closes: #641834
   * Use --srcdir and --destdir po4a options, and bump Build-Depends version
     to 0.36.4.
 .
   [ Updated dpkg translations ]
   * German (Sven Joachim). Closes: #620312
   * Swedish (Peter Krefting).
   * French (Christian Perrier).
 .
   [ Updated man page translations ]
   * French (Christian Perrier).
   * German (Helge Kreutzmann) including improvement by "Flo".
   * Swedish (Peter Krefting).
 .
   [ Updated scripts translations ]
   * French (Christian Perrier, Sylvestre Ledru). Closes: #637096
   * German (Helge Kreutzmann).
   * Swedish (Peter Krefting).
Checksums-Sha1: 
 d8d9d5a8a9f134459987f5b187527c303498e902 1364 dpkg_1.16.1.dsc
 9e8176c88fe2b31782ddae6d0a8f599c7e540e8d 5432348 dpkg_1.16.1.tar.bz2
 a830d5633da7a96d5208a6f8a7a97e24865e7913 552790 libdpkg-dev_1.16.1_amd64.deb
 470de180ac9fa5c95abfcf30a4d9a46cab269107 2218686 dpkg_1.16.1_amd64.deb
 6e6ddbb681d1bbbb971299932f99d43a35f33750 1006884 dselect_1.16.1_amd64.deb
 b8394b2dfd4291ff206dec00e53c723fa0be902e 923836 dpkg-dev_1.16.1_all.deb
 7940dc852c11e3a386ce014cd39ab7ce30e34f30 806604 libdpkg-perl_1.16.1_all.deb
Checksums-Sha256: 
 3f1649796856228545ba610df340b47b923a31f6ebe8765c8f48e1dac7f11391 1364 dpkg_1.16.1.dsc
 f9363628a6fa1c24a1e9c41bd8977f9d5a7010bfca3ac9a6f8bf500e7e8df52b 5432348 dpkg_1.16.1.tar.bz2
 96910fa1ed1371aa2b9e3147eecdf67e4e5f61fe7d7aaa97c27254f55a92c56d 552790 libdpkg-dev_1.16.1_amd64.deb
 d0e9691aa05c1b2567b06df0856ea05a211234e40dbc955e0266fa45fb32370c 2218686 dpkg_1.16.1_amd64.deb
 4a1c44c98791f1aa1b59bfc4890a3f6aeef70319f930e1ca9b7354ede8e78125 1006884 dselect_1.16.1_amd64.deb
 885d13576b93262151b5e920dd8971072668c0bd36b103ab0e82b97fcef52fcd 923836 dpkg-dev_1.16.1_all.deb
 b6fa511f2b059a85e3d5938c73a5805893a28438785a974bf0e46a53dc5da975 806604 libdpkg-perl_1.16.1_all.deb
Files: 
 c1e7858da79770b64427a99cc628889c 1364 admin required dpkg_1.16.1.dsc
 b94c9ed2493fd9dbb53a96f2e7f674ce 5432348 admin required dpkg_1.16.1.tar.bz2
 99bbb9c901e7462d06472a27ffb6d67f 552790 libdevel optional libdpkg-dev_1.16.1_amd64.deb
 bed79ea34df74b42ebbc2ed13d3ed4cb 2218686 admin required dpkg_1.16.1_amd64.deb
 bd018624eca8f1cf04a0b588a6338622 1006884 admin optional dselect_1.16.1_amd64.deb
 78c00b38545303cf8c8fcd4dd83f30a3 923836 utils optional dpkg-dev_1.16.1_all.deb
 f604975f555da4f710167be2b0d468f7 806604 perl optional libdpkg-perl_1.16.1_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk58Dr0ACgkQuW9ciZ2SjJtZVwCgkPiancaq9ojJ2L0b8uEEjSC7
87YAoKtmUCgXZS/CfakXx860t2ijO84f
=Cq2h
-----END PGP SIGNATURE-----





Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Mon, 31 Oct 2011 07:35:04 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Mon Apr 21 13:13:41 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.