Re: binNMUs?
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.
> On Thu, 15 Sep 2011, Guillem Jover wrote:
> > 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.
While the way the infodb is currently scanned to select pkg specific
control files is not optimal, the cost of this operation (even with
an increase in the number of files) is not significant and as such is
a non-issue. It's just reading few disk blocks (if at all), and doing
string comparisons.
But regardless, that does not seem a valid concern, *if* for whatever
reason there was some noticable cost, then the correct course of
action is to fix dpkg to use a more optimal infodb layout (like
poolizing it, which has crossed my mind already several times).
> 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. 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.
regards,
guillem
Reply to: