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
