Re: binNMUs?
Hi!
On Mon, 2011-09-12 at 21:19:29 +0200, Andreas Barth wrote:
> * Steve Langasek (vorlon@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
Reply to: