Re: trimming changelogs
Hi Adam,
Thank you for putting this forward, but actually I'm personally
object to trimming changlogs from a normal[1] system. A complete
changelog helps me quickly understand what happened to the <keyword>
component of the package. Once trimmed, such changelog get crippled. Why
not directly keep only the latest dch section? People who need the full
log can look up the packaging repository.
That said, I agree that we move a step further considering a slim base
system in a more constructive way. Spontaneously, I'd raise such a
question: Is the changelogs the only files to blame for the waste of
precious space? Some packages contains lots of unnecessary HTML/PDF/.*
documentations/resource/assets which are very likely useless on those
low-storage systems. Who is going to read long documentations on a weak
embedded device?
Here is my bold idea: we create a (new) special mode oriented for
low-storage systems. For important packages (that exist in stage{3,4}),
maintainers mark those unnecessary files as "trimmable". On
installation, the dpkg automatically ignores the "trimmable" files
once the "low-storage" mode has been toggled. For differnent "trimmable"
files we can write different trimming helpers (such as the one for
changelogs).
^^^ In this way we may be able to solve all system storage headaches for
people working on embedded device.
If we decide to invest our energy in trimming the base system, we should
think about the "trimming stage3" problem in a more systematical way.
[1] where 10MiB less available space is never a problem
On Fri, Mar 20, 2020 at 12:50:29AM +0100, Adam Borowski wrote:
> Hi!
> In the rush for cutting away small bits of minbase, it looks like we forgot
> a big pile of junk: /usr/share/doc/
>
> On strict minbase (rather than prio:important which really matters), the
> docs take 11MB. And of that, 8MB are files named changelog.* -- which
> fails to include eg. bash's:
> 112K -rw-r--r-- 1 root root 111K Jan 2 2019 CHANGES.gz
> 8.0K -rw-r--r-- 1 root root 8.0K May 29 2018 COMPAT.gz
> 4.0K -rw-r--r-- 1 root root 2.9K Feb 17 1999 INTRO.gz
> 32K -rw-r--r-- 1 root root 30K Nov 13 2018 NEWS.gz
> (INTRO.gz is small, but 1999 advertising is of little use)
>
> Of files named changelog.*, top offenders are:
> 880997 dpkg:changelog.gz
> 381250 gpgv:changelog.gz
> 289255 libgnutls30:changelog.gz
> 223009 ncurses-bin:changelog.gz
> 223009 ncurses-base:changelog.gz
> 223009 libtinfo6:changelog.gz
> 210621 libc6:changelog.Debian.gz
> 210621 libc-bin:changelog.Debian.gz
> 202841 dpkg:changelog.Debian.gz
> 193825 coreutils:changelog.gz
> 177117 gcc-9-base:changelog.Debian.gz
> 176608 gcc-10-base:changelog.Debian.gz
> 164010 findutils:changelog.gz
> 147656 tar:changelog.gz
> 145889 libapt-pkg6.0:changelog.gz
> 145889 apt:changelog.gz
> 145271 passwd:changelog.gz
> 145271 login:changelog.gz
> 142058 grep:changelog.gz
> 131424 libp11-kit0:changelog.gz
> 123812 libgcrypt20:changelog.gz
> 113533 bash:changelog.gz
> 103492 libnettle7:changelog.gz
> 100216 libpcre3:changelog.gz
> 93638 libudev1:changelog.Debian.gz
> 93638 libsystemd0:changelog.Debian.gz
> 63709 perl-base:changelog.Debian.gz
> 63670 logsave:changelog.Debian.gz
> 63670 libss2:changelog.Debian.gz
> 63670 libext2fs2:changelog.Debian.gz
> 63670 libcom-err2:changelog.Debian.gz
> 63670 e2fsprogs:changelog.Debian.gz
> 63284 tar:changelog.1.gz
>
> Seems like a tempting area to trim...
>
>
> Prior art:
> sysvinit does:
> sed -i -ne '/sysvinit (2.93-8)/q' -e p \
> $(rctmp)$(doc)/sysv-rc/changelog.Debian
> (I've just bumped the cut-off from 2.86.ds1-47, in 2007)
> which also differs per binary package.
>
> Ubuntu keep only 10 last entries, for _all_ packages.
>
>
> I consider 10 entries to be too little for a fast moving package ("upload
> early, upload often"), but a release-based ("since oldstable"), time-based
> ("3 years ago") or size-based ("X 4096 filesystem pages after gzipping")
> cut-off would work well.
>
> 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.
>
> Thoughts, folks?
>
>
> Meow!
> --
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
> ⢿⡄⠘⠷⠚⠋⠀ -- <willmore> on #linux-sunxi
> ⠈⠳⣄⠀⠀⠀⠀
>
Reply to: