Re: trimming changelogs

[Guillem Jover <guillem@debian.org>]

Hi!

On Fri, 2020-03-20 at 00:50:29 +0100, Adam Borowski wrote:
> In the rush for cutting away small bits of minbase, it looks like we forgot
> a big pile of junk: /usr/share/doc/

As has been mentioned on the thread, this is IMO a non-issue, as these
pathnames can be trimmed automatically with dpkg path-excludes.

> On the other hand, changelogs are valuable.  Unlike some folks on IRC
> I wouldn't want to tightly trim all packages.  Unlike minbase or
> prio:important, your average 5GB install doesn't care about a few megs
> here and there.  Thus: do we want to trim manually or globally?
> 
> A global trim would require a lot less work.  A manual trim would allow
> managing packages: dpkg is everywhere, dpkg-dev is not.  libsystemd0 is
> essential, systemd doesn't belong in containers.  gcc-9-base is included
> on tiny installs, gcc-9 on dev boxes and buildds with plenty of space.
> Plus, manual trimming would also allow axing old upstream cruft.

TBH I find trimmed changelogs rather annoying. We already got problems
with changelogs that omit information (say a salad of Closes for bugs
fixed in a new upstream version), or non-descriptive changes, or
outright omitted changes, etc. To me trimming them and making it a
habit of having to download them from the network, triggers the question
of why we'd even ship them? (Just to be clear I'd find that to be a
worse decision. :)

Doing that trimming globally would also mean that this applies even
to packages that are for local or derived use where something like
«apt changelog» will in most cases not work.

A proposal I've been floating around from time to time has been to
instead make the changelog and copyright files deb/dpkg metadata
(which they really are anyway IMO). This would allow the following
properties:

  - The interfaces would become something like dpkg --show-copyright
    or dpkg --show-changelog, with a pager f.ex., which is more
    obvious for new people to discover than having to look for a file
    in the filesystem.
  - Extracting them for apt-listchanges and similar would be way way
    quicker (needing to extract the .deb control member instead of
    the data control member).
  - The contents could get compressed in whatever format is most
    appropriate (xz f.ex.).
  - The contents could get automatically de-duplicated on demand.
  - The contents could be configured to be dropped as well.
  - The changelog file would stop being a problem for multiarch binNMUs.
  - This would get rid of most of the issues with symlinked
    /usr/share/doc dirs(?), and the contents would always match the
    package version instead of now when sometimes we end up with
    mismatched content and version if the dependencies are not strict
    enough.

Thanks,
Guillem