RFC: RPM Changelog thoughts

[Paul W. Frields]

On Mon, 2005-10-31 at 07:40 -0600, Tommy Reynolds wrote:
> I'm looking at the RPM packaging steps that Paul has done.  AIUI, he
> uses a small python script to pick the changelog information out of
> the document's XML.  Cool idea.

It is, if only I were indeed doing that!  The only thing I do is a grab
of the title information out of <title> within the <book> or <article>.
I am just learning Python baby steps, so even that was a stretch.
Didn't want to take credit where it wasn't due.  I had considered this,
though, as an eventual goal for Python learning... if I could figure out
enough SAX stuff to make this work, that would be a real coup as far as
I'm concerned.  I was under the impression that there were ways to even
parse and read back entities, but I have no idea if that's a correct
impression.

> My question is this: should we build the RPM changelog from the XML
> content or from the CVS check-in log?  Using the XML info is way
> cool, but we can get more file-specific information from the CVS log.
> I think developers, er, RPM users, would like the additional details.
> 
> Opinions?

I think the CVS log would be nice, but my understanding is that it's
difficult to parse for this content.  A couple difficulties that
occurred to me were (1) tying the CVS login name to an email address,
which is normally used in the spec file's %changelog; (2) mitigating the
situation with the CVS changelog having entries that do not correspond
to RPM package versions -- in other words, CVS gets revisions for which
a new package is not rolled; and (3) tying the CVS revision number into
a version number used for the RPM package.  I don't know if any of these
are showstoppers, but they are definitely gobsmackers, if you get my
meaning.

On the other hand, the DocBook XML <revisionhistory> at least has a
"rational" version number and date which should roughly correspond with
packaging.  We still have the email address problem, however, and other
problems likely exist with this way of doing it.  *sigh* This is so much
easier dealing with regular code like in Extras!

-- 
Paul W. Frields, RHCE                          http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/docs/attachments/20051031/eae07e56/attachment.bin