[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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,


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.


[1] The time spent removing features from debhelper is literally
measured in decades.

Reply to: