Brief (and early) ode to fedpkg

[Bernie Innocenti]

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.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/