Brief (and early) ode to fedpkg

[Jesse Keating]

On 1/24/11 7:21 PM, Bernie Innocenti wrote:
> 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?

Sure it's possible, that'd have to live server side though, unless we 
put the logic into fedpkg itself.  With git the commit happens and then 
at some future time you ship off your commits to the remote server.

>
> 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.

Well you're talking about yum and rpm here, yes we strip out changelog 
data from the yum metadata because it's frequently downloaded.  Once on 
your system though the changelog lives in the rpm database.  As to 
whether or not it takes up more space if you have multiple subpackages 
installed is a question for the rpmdb folks.  Seems like a fairly easy 
thing to just keep a reference.

>
> 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).

Nothing, except massive amounts of coordination around upstream rpm, who 
are busy with other rather more important tasks right now :)

>
> I'm just throwing around a bunch of ideas to think about... simplifying
> the fedora packaging workflow is an important goal, imho.
>

Indeed.


-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating