Re: Bug#954313: dh_installchangelogs: provide option to strip off old changelog entries
Control: tags -1 moreinfo
Michael Biebl:
> Package: debhelper
> Version: 12.9
> Severity: wishlist
>
> Hi,
>
Hi,
Thanks for the suggestion. :)
(CC'ing d-devel because I think this is relevant to the discussion there)
> some packages have a very detailed debian/changelog which goes back
> years or even decades.
>
> Given that we nowadays have the ability to get changelogs on-demand via
> "apt changelog", I think it would make sense if the changelog.Debian
> that is installed on disk can be trimmed down.
>
> While I surely can do that via some sed hacks in debian/rules, a nicer
> option would be, if dh_installchangelogs would provide an option like
> say --trim=365d / --trim=2y / etc, which would only install changelog
> entries that are newer then 365 days / 2 years / etc.
>
> 2 or 3 years sounds like a good compromise to me, as this would cover
> changelog entries dating back to the last stable release.
>
> For the time being, I would make that opt-in, i.e. packages have to
> override dh_installchangelogs. Maybe at some point in the future,
> something like --trim=3y could be made the default behaviour with a new
> compat bump.
>
> I vaguely remember that Ubuntu does something similar in that regard.
> I've CCed Julian, maybe he can provide some input.
>
> Regards,
> Michael
>
> [...]
I think we owe ourselves to be honest and agree whether we do this or
not. The proposed opt-in solution will almost certainly end up being a
slow translation to saying "yes we are going to do this" - it will just
defer the answer 5 - 10 years with a lot of extra work.
And if we are going to that, I would rather do it fully automatic from
the start. Either "flag day"-style or "next compat level"-style.
This would save everybody else time and energy learning and unlearning a
command option that you have to sprinkle into your package to have
debhelper "DTRT".
And would save me from adding an option and then spend a decade
removing it again because it has become obsolete[1].
Lets not add "yet another papercut" to our packaging process.
On the topic of derivatives: I am happy to hear from derivatives that
have different needs for changelog trimming. As mentioned in the d-d
thread, there is Ubuntu which is currently the only one I am aware of.
~Niels
[1] The time spent removing features from debhelper is literally
measured in decades.
Reply to: