Hi,
On Thu, 15 Sep 2011, Guillem Jover wrote:
> 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?
I think the various people who participated in the discussion did not
mean the same thing... :-)
> 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.
I agree that dpkg-deb should have nothing to do for this specific case.
I have suggested that the binnmu changelog (which is a single line, or
could easily be constrained to a single line) should just become a new
control header so that the changelog can be installed unmodified. This
could be injected by dpkg-gencontrol based on some information provided
by dpkg-buildpackage (likely a specific environment variable).
The version number to use for the binary packages would be also
dynamically generated by appending some extension to the version
number seen in debian/changelog. This would even allow to use
something else than +bX for bin-nmu which is desirable for many
other usages (backports, PPA, etc.).
> 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).
While this sounds nice, I don't like the cost it imposes on all dpkg
runs... the info directory is scanned frequently and adding files that
don't have to be there is not a good idea IMO.
Also some packages are providing the changelog in a -common package
to avoid its duplication, and this change would not allow something like
this without some special handling.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)