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

[Ian Jackson]

Guillem Jover writes ("Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU	broke multi-arch installability"):
> 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.

I think this is the wrong design.  The changelog is primarily used by
humans, not software, and burying it in the dpkg database is not
helpful.  I think the solution with the binNMU changelogs is
straightforward and should be implemented.

>  * 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...

This path leads, eventually, to all structured data currently stored
in the filesystem being subsumed by dpkg.  This is not healthy for
dpkg and not healthy for the rest of the project.

Ian.