Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow to keep a minimum number of changelog entries #931

Open
wants to merge 1 commit into
base: master
from

Conversation

@bmwiedemann
Copy link
Contributor

bmwiedemann commented Nov 8, 2019

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

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
@Conan-Kudo Conan-Kudo mentioned this pull request Nov 8, 2019
@pmatilai

This comment has been minimized.

Copy link
Contributor

pmatilai commented Nov 8, 2019

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

This comment has been minimized.

@Conan-Kudo

This comment has been minimized.

Copy link
Member

Conan-Kudo commented Nov 8, 2019

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

This comment has been minimized.

Copy link
Contributor

mlschroe commented Nov 8, 2019

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

This comment has been minimized.

Copy link
Contributor

pmatilai commented Nov 11, 2019

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

This comment has been minimized.

Copy link
Member

Conan-Kudo commented Nov 11, 2019

@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

This comment has been minimized.

Copy link
Contributor

pmatilai commented Nov 11, 2019

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

This comment has been minimized.

Copy link
Member

Conan-Kudo commented Nov 11, 2019

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

This comment has been minimized.

Copy link
Contributor

pmatilai commented Nov 11, 2019

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

This comment has been minimized.

Copy link
Contributor

pmatilai commented Nov 11, 2019

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

@Conan-Kudo

This comment has been minimized.

Copy link
Member

Conan-Kudo commented Nov 11, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.