Hi,
在 2020-03-20星期五的 00:50 +0100，Adam Borowski写道：
> Hi!
> In the rush for cutting away small bits of minbase, it looks like we forgot
> a big pile of junk: /usr/share/doc/
> [...]
> Seems like a tempting area to trim...
> [...]
> 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.
My 2 cents: no matter whether we are trimming for all packages or some key
packages, I'd expect such trimming to be _fully_ automatic, e.g., performed by
a tool of dh_*. Manual trimming would be another extra burden for package
maintainers. I'm not sure how Ubuntu implemented this but probably we should
be implementing it at the same location.
Also I'd assume that the source package always contains the full changelog.
Maybe we can keep changelog of up to 10 entries or till the time of 5 years
ago (I'm just providing a random number; it can be adjusted), whichever is
greater. The exact entries to keep is determined by using SOURCE_DATE_EPOCH as
the current time to maintain package reproducibility.
--
Thanks,
Boyuan Yang
Attachment:
signature.asc
Description: This is a digitally signed message part