On Sun, 2016-10-23 at 19:46 +0200, Michael Schwendt wrote:
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.
That's pretty much the exact *opposite* of what I put in the changelog,
FWIW. For me, that stuff goes in the git commit message (and even then
I don't really break it down in that much detail, because the tools
make it easy to see *what* changed, the thing the commit message has to
fill in is *why*). What goes in the package changelog is changes that
actually make a concrete difference to a *user* of the package. They
don't give a damn about the BuildRequires changing.
Of course, the reason we have a different opinion on this is simple:
because the distinction postdates the design of RPM and we've never
come up with a widely-followed formal policy on this stuff. We weren't
storing package specs in git (or in a VCS at all, I don't think) when
RPM was invented, so the package changelog got all the information (or
at least, it *should* have done; skeletal changelog entries are very
common in old packages, sadly).
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net