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) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
