Hi! On Mon, 2011-09-12 at 21:19:29 +0200, Andreas Barth wrote: > * Steve Langasek (vor...@debian.org) [110912 20:44]: > > On Thu, Aug 25, 2011 at 08:19:09PM +0200, Julien Cristau wrote: > > > On Mon, Aug 1, 2011 at 15:31:56 +0200, Andreas Barth wrote: > > > > Also, I think we still have a reason for +b(something) as sometimes we > > > > just need to rebuild on a single architecture (because something > > > > strange has happend there), and I don't want to get rid of that > > > > ability. > > > > > The more I think about it, the more I think we should move the binNMU > > > changelog out of /usr/share/doc and allow co-installation of different > > > binNMU versions of multi-arch: same packages. (IOW: agreed) > > > > Any reason not to ship it as /usr/share/doc/$pkg/changelog.$arch? (I.e., I > > think /usr/share/doc is still the right place for it, even if it can't be > > changelog.Debian.gz anymore.) > > I would rather do /usr/share/doc/$pkg/changelog.$arch.$binNMU - but > well, YMMV. Anyways, I think that dpkg-deb should inject this files > e.g. from an entry in the control file. Otherwise, it might be too > difficult to get this done.
I'm not sure I follow. Do you mean this file would only contain the binNMU revision changelog entry, or that it would append it to the source changelog and move it to that new path, or both would be installed alongside (or maybe something else)? And the binary control field would get that field added how? In any case this looks rather ugly, and implies dpkg-deb has to start changing the contents before build, which is something I've said before (in others contexts) I don't want to see it start doing. That would imply dpkg-deb needs to know about packaging policy decision, and file system layout, etc. The most it should do is verify the control member for things it knows about. What comes to mind, even if slightly radical, is that the Debian changelog file makes more sense as being part of the .deb control member, and as such end up under the dpkg database. Which would elegantly solve the co-installability problem, and would allow for stuff like “dpkg --changelog foo” or “dpkg-deb --changelog foo.deb” to work reliably (similar to the rpm counterparts). At least that would make its access uniform (after the transition period has ended), compared to diverging paths depending on the package being multiarch + binNMUed, etc. Both of which break current path assumptions anyways. And lastly, whatever solution, the problematic packages are multiarch enabled ones, which have needed manual modifications, so they can as well still be modified to catter for any change in handling the changelog. regards, guillem -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110915065636.ga17...@gaara.hadrons.org
