On Sun, 23 Oct 2016 16:21:25 +0000, Christopher wrote:
> Our rules is "leave it to the packager's personal
preference" and to
> "keep what's important".
I'm curious, what *IS* important?
1.) Don't copy upstream changelogs into the spec %changelog.
2.) Mention everything that may affect whether the packaged software
no longer works, such as added/removed patches, added/remove BuildRequires,
added/removed explicit Requires, replaced source tarballs, changes to the
build process, rebuilds (note that rebuilt dependencies may cause
breakage, too, so both users and maintainers may read %changelogs and
figure out what components had been touched before something has caused
breakage), changes to custom installation in %install as well as to the
scriptlets/triggers.
Note that infamous "spec rewrites", which have not been mentioned in the
%changelog and not in a git commit comment either, have been the culprit
of breakage several times before. Even simply changes, such as re-indentation
and replacing tabs with spaces (or vice versa), also has caused breakage
because of introducing bugs into the spec file OR leading to a completely
unnecessary rebuild that produced broken builds (as a result of building
with changed build requirements).
Who are the consumers of this information?
Both the packager users and package maintainers.
git history seems to suffice for maintainers (and, is probably
far more useful than the changelog).
It's not available locally. And both git and %changelog may be older
than the actual build of the package. It's always more convenient to
query the installed package metadata.