[xml/sgml-pkgs] Bug#676686: Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability

[Guillem Jover]

On Sat, 2012-06-09 at 15:26:06 +0200, Andreas Barth wrote:
> * Henrique de Moraes Holschuh (hmh at debian.org) [120609 02:31]:
> > We'd just have to teach the tool to binNMU all arches when the target
> > package would need it due to multiarch.  Release team requests a binNMU of a
> > package for some arch, the tool notices it has to do them all because of
> > multi-arch constraints, and replicates the request for all other arches.
> 
> Just that this won't do it, because the changelogs for the different
> arches will be binary different, so no win.
> 
> However, we discussed that during the multi-arch bof last Debconf, and
> came to the conclusion that it would be better to not modify the
> changelog as we do now, but instead create a new file
> changelog.$arch.$version with the binNMU. This is a bit more
> complicated because it can't be done as of now just within the source
> package.

As I mentioned in the long ref-counting thread, I strongly disagree this
is a correct solution, it just seems like a hack to me. Instead I
think we should consider changelog (and copyright as long as it's in
machine parseable format) as dpkg metadata (something dpkg misses
compared to rpm or other package managers for example) and as such they
should go into the .deb control member, which would end up in the dpkg
database w/o any kind of file conflict, and very minor packaging effort
as for most that would be handled by helpers.

This has (at least) the following advantages:

 * no need to concat different files to get the complete changelog.
 * the version in the changelog would match the package binary version.
 * the changelog file would *always* get to be referred by the same
   name regardless of the package being native, binNMUed or otherwise.
 * changelog extractors (like apt-listchanges) would not need (eventually)
   to extract the whole .deb data member to get the changelog, it
   would just need to extract the control member, and get a fixed
   filename. They would stop needing to hardcode possible paths to
   the files too. This still leaves the NEWS.Debian file but then
   maybe that should also be considered metadata...
 * dpkg can gain new commands to return/show these files reliably w/o
   needing (eventually) to hardcode the distribution's specific path
   (which is a matter of fileystem policy dpkg does not really need
   or has to know).
 * dpkg eventually could do a way better job at reducing duplicated
   data, by for example transparently hardlinking them, instead of our
   ad-hoc doc dir symlinking.
 * dpkg could reduce space usage by transparently compressing them
   with something better than gzip.
 * (minor) it's a common pattern to want to exclude all of
   /usr/share/doc/pkg but the copyright file, storing it elsewhere
   would avoid that.

To that end, last month I cooked a preliminary patch for dpkg to add two
new commands: --show-changelog and --show-copyright, that take a package
name and print to stdout (through a pager if on a terminal) either of
those files, and fallback to a configurable set of paths on the
filesystem if the requested file is not in the database (decompressing
them if need be).

regards,
guillem