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

[Guillem Jover]

On Mon, 2012-06-11 at 11:39:24 +0100, Ian Jackson wrote:
> 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.

Well, the dpkg suite makes extensive use of the changelog to retrieve
all kinds of information, dpkg (the program) does not currently access
it though, but that data is still package metadata. The same could be
said about some fields in the control file and it still makes sense to
have them there, because again it's package metadata. There's also other
precedent of package metadata not handled directly by dpkg (currently
or in the past) which gets installed in the info database, like
templates, config, md5sums and clilibs, for some I'm aware of.

I disagree placing it in the dpkg database is not helpful, for a user
or other programs wanting to access that structured package metadata
it's obviously easier and better to do something like
«dpkg --show-changelog foo» or «dpkg-query --control-path foo changelog»,
than having to go hunt where in the filesystem the changelog might be
located, regardless of distribution path polcies. The same for the
copyright information, and I've actually been asked in the past why dpkg
does not have a command to show package copyright information. I've
listed the other reasons (which you trimmed) in the parent mail.

And if by “the binNMU changelogs”, you mean the split changelog solution,
I still disagree that's the correct avenue. It means the information
of why the package was rebuilt either ends up in yet another different
place on the filesystem, or lost if the helper does not get updated to
cope with that or if the package does not use any helper, which is
still a non-insignificant amount of the archive. It might also break
with packages poking at the debian/changelog file directly as Jonathan
mentioned, or external software accessing the source tree, because
debian/changelog is an interface, and while it might seem like a
straightforward solution it looks like it will cause more problems
than the ones it solves, and it still seems like a workaround.

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

Eh, only structured data that is packaging metadata. TBH, I don't see
other clear candidates besides changelog and copyright (maybe even
NEWS.Debian, but this one might be a stretch), and those two are
clearly package metadata.

So, I'm still unconvinced by the arguments you brought up.

regards,
guillem