Allow to keep a minimum number of changelog entries

[bmwiedemann]

Allow to keep a minimum number of changelog entries
because some tools and workflows break when %_changelog_trimtime
dropped all entries.

This also helps reproducible builds because
%source_date_epoch_from_changelog can only work when there is an
entry left

Note: test looks good. e.g. mtimes get adjusted again with %clamp_mtime_to_source_date_epoch Y

[pmatilai]

Nothing against the functionality.
IIRC Suse has been carrying a patch to do something like this for a longer time, and in that case we should at least consider compatibility issues. @mlschroe ?

[bmwiedemann]

https://github.com/bmwiedemann/openSUSE/blob/master/packages/r/rpm/rpm-shorten-changelog.diff maybe?

[Conan-Kudo]

Yeah, the SUSE patch implements a "hard cutoff" date as opposed to RPM's built in "range cutoff".

EDIT: Ignore me, I'm dumb here, that's not what this patch does.

[mlschroe]

Yes, we have %_binarychangelogtrim. The syntax is:

%_binarychangelogtrim maxnum,cuttime,minnum

It is only applied to binary packages, i.e. the source rpm still has the complete changelog.

[pmatilai]

Okay, there are multiple intertwined things here.

%source_date_epoch_from_changelog must work regardless of any trimming options, as long as there is a %changelog in the spec. And then there's the overall sanity need for keeping N changelog entries even if they're older than some cut-off date.

I also agree with Suse here in that trimming the changelog in the binary packages is what is interesting, and perhaps src.rpm changelog should simply be left alone at all times.

Doing that would actually simplify things somewhat:

• parse changelog as-is into the spec source package header, always
• use the source (instead of first binary) package header changelog for SOURCE_DATE_EPOCH
• apply whatever filters necessary when copying the changelog from source to binaries (avoiding the need to modify afterwards as the %_binarychangelogtrim patch does)

[Conan-Kudo]

@pmatilai That makes sense to me. Though I could easily see people wanting the source package changelog header being trimmed too, since the full changelog is also present in the spec file. Perhaps a tunable to switch the behavior, and default to only trimming binary package changelogs?

[pmatilai]

The thing is, there's preciously little saved anything for truncating src.rpm changelogs. Unlike binaries, they aren't getting downloaded over and over on each update people make, and don't occupy space in everytbodys rpmdb, and multiple times at that - with everybody going to smaller and smaller sub-packages, it gets more and more ridiculous.

[Conan-Kudo]

I guess so... I was mainly thinking of the time it takes to generate repodata, as having long changelogs adds a fair bit to the other.xml file...

[pmatilai]

A few more lines of text data per package is not going to kill repodata generation speed. Again, this is all different in the land of binaries where it all multiplies through the roof: take rpm package in Fedora, there are 16 sub-packages in total, and with the exception of -apidocs and -cron, all get a -debuginfo package to go with it. Add to that -debugsource package and you have 31 duplicates of the changelog data. THAT will start hurting performance, disk-space consumption and all.

[pmatilai]

It'd be considerably saner to split changelogs into meta-packages that all the sub-packages depend on...

[Conan-Kudo]

Fair point. Okay, I'm convinced that we should change that to just affect binary packages...

[pmatilai]

Addressed in a slightly different way in #1328: always trim using age relative to newest changelog entry (nice idea by @ffesti ). This way we don't need multiple variables to manage the trimming, at least one entry is always preserved, the time doesn't need constant adjustment, and the output is reproducable (when %_changelog_trimage, auto-conversion from the deprecated and rather broken %_changelog_trimtime might not be in edge-cases)

[ffesti]

With #1328 merged I am not sure if we really want to add another feature to control changelog behaviour right now. Closing.