On Mon, 2011-01-24 at 16:46 -0800, Jesse Keating wrote:
That's a bit of a struggle, as there are times when you want something in the scm changelog that isn't really appropriate for the rpm changelog, like fixing a typo in the specfile between build attempts. We do provide the clog facility so that one can re-use the spec changelog for the SCM changelog when appropriate. I've also explored a bit using a %include directive to include contents from a changelog file, one that might be auto-generated from source control, but I didn't go very far with it.
Basically I view the scm changelog as data that is relevant and important to your fellow maintainers, where as the rpm changelog is data that is relevant and important to the rpm consumers. While there is some overlap, they are not the same consumers.
The old KDE 1.0 CVS repository used a sophisticated commit hook which would interpret tags in the comments such as CVSSILENT, CVSFEATURE or CVSSECURITY to suppress the notification email or add more recipients on cc.
Couldn't we do something similar for suppressing entries we don't want to see in the package changelog?
Besides: the changelog feature of rpm always stroke me as something so... gross! It is part of the package metadata, but due to size considerations it's not really part of the primary repodata. For multi-package specs, you end up with multiple copies of the same changelog in the rpm database. Moreover, RPM-based distributions use different incompatible formats for %changelog! Not to mention that the % changelog section is where you get 90% of the merge conflicts when porting changes between branches.
By contrast, .deb packages simply include a compressed text file: /usr/share/doc/$PKG/changelog.gz. Why couldn't we switch to something similar and thus remove a lot of complexity from the rpm toolchain? (the package changelog is maintained manually, but Debian doesn't have a distro-wide package VCS).
I'm just throwing around a bunch of ideas to think about... simplifying the fedora packaging workflow is an important goal, imho.