Re: binNMUs?
On Wed, 02 Nov 2011, Guillem Jover wrote:
> On Thu, 2011-09-15 at 14:29:00 +0200, Raphael Hertzog wrote:
> > 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.).
>
> These look like hacks to me.
For me it's the current bin-nmu support with special casing in the
subsvars generation code that seems a hack to me.
Designing a new interface to specify a "binary build version" that differs
from the source version seems like something really useful. The details
do not need to be precisely the one I presented above. But I would very
much like have a clean solution where we get rid of the +bX being the
only possible extension for bin-nmus.
(And really I can't respond to "these look like hacks" if you don't give
more details to what you consider "hackish"...)
> > 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.
>
> There's no special casing needed at all, what would happen would be
> that a hardlink is created based on the source package name (as long
> as they are the same). This also would give the immediate benefit of
> reducing huge duplicated changelog and copyright files, for free (as
> in no packager action required), while in addition complying to the
> letter on each binary package ships with a proper copyright file.
There's also the fact that up to now you can avoid installing the
changelog with --path-exclude and if it becomes part of the control files,
you need a new solution to make the space saving...
> If OTOH it would be decided we really want to keep not shipping those
> files in some binary packages then symlinks could be created when
> those are missing.
Pointing to what?
It seems to be a bad idea to mix the source package namespace and the
binary package namespace in the infodb. So I don't really like your
suggestion to have a reference copy of the file based on the source
package name.
We already had pathological cases where a binary package foo was not built
by the source package foo. Even if we prefix those files with "src:"
to avoid the collision, we're introducing the notion of source package
at a level that should really only care of the binary packages.
OTOH, this is also partly required if we want to allow co-installation of
M-A: same packages with different binary versions but the same source
version... (the difference being that in the former the source package
name matters and in the latter it's the source version that matters)
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/go/ulule-rh/
Reply to: