Re: trimming changelogs
On Thu, Mar 19, 2020 at 08:58:57PM -0400, Boyuan Yang wrote:
> 在 2020-03-20星期五的 00:50 +0100，Adam Borowski写道：
> > [trimming changelogs]
> >
> > 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_*.
Of course, doing this by handcrafted code would be bad.
mbiebl just filed #954313 asking for a dh_installchangelogs option.
> 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.
By "manual trimming" I mean manually enabling it / selecting what to trim.
Ubuntu instead does "global trimming", which affects all packages, not just
base. I find that somewhat wrong: today, even small ARM boards use a SD
card of 16+GB -- and embedded systems are handcrafted anyway. You don't
care about minor savings on an the primary (host) system.
Reducing minbase matters for containers and similar cases that cram hundreds
of Debian installs onto the same box.
> Also I'd assume that the source package always contains the full changelog.
Aye.
> 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.
Right -- and if we'd be able to adjust packages to choose how aggressive the
trim should be per-binary (dpkg vs dpkg-dev), I'd be happy.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀ -- <willmore> on #linux-sunxi
⠈⠳⣄⠀⠀⠀⠀
Reply to: