[RFC] Packaging technology update

[Paul W. Frields]

On Sat, 2005-11-26 at 13:18 -0600, Tommy Reynolds wrote:
> Uttered "Paul W. Frields" <stickster at gmail.com>, spake thus:
> 
> > - I wonder if it would be wise to have a change to the DTD which offers
> > a 'release' in addition to 'version' for a 'revision', such that:
> > 
> >   <revision date="Sat Nov 25 2005" version="0.1.3" release="1">
> > 
> > would be allowed.  The latest release number would be the thing that
> > appears in the %release tag.  The 'release' element that falls directly
> > inside 'rpm-info' would be eliminated.  There is always a chance that
> > things have to be repackaged because an OMF or .desktop file is updated
> > -- or even the spec template -- but not the doc content, which calls for
> > a release bump, not a version bump.  Is such a thing possible, Tommy?
> 
> My thought was that the /rpm-info/release value would represent the
> RPM packaging release cycle.  

Ah, I see, that makes sense... IOW we would hope that if we do this
right that might never change, right?  Sorry, forget that snippet above,
then.

> The <revision> components of the
> <changelog> would generate both the RPM %changelog and the DocBook
> revision log.

> Hm.. would a "role='rpm'" attribute on the <changelog>/<revision>
> element suffice?  I could then just skip that entry when building the
> DocBook history.

Well, I think having that sort of structure makes sense, in that some
changes will be packaging only, and some changes will be document only.
It probably makes sense for the document revision history to be in the
RPM %changelog but not the other way around.  What if we were to use
some of the XSL "if" statements to perform some of that magic, and have
a hierarchy like this:

  <changelog>
    <revision type="doc">
      <date>2005-11-20</date>
      <authorinitials>PWF</authorinitials>
      <details>Some guff here</details>
    </revision>
    <revision type="rpm">
      <date>Sat Nov 26 2005</date>
      <packager>
        <name>Paul W. Frields</name>
        <email>stickster at gmail</email>
      </packager>
    </revision>
  </changelog>

> > Just some quick ideas...  I'm not really conversant with a lot of XSLT
> > stuff so I may piddle around with this, but not expecting great things
> > as a result. ;-)
> 
> Neither am I, but if you can help get the prototype SPEC, OMF, et.
> al., files right I think I can mangle the XSLT stuff enough to get
> by.

I am doing some DTD and XSLish reading... your new additions here have
helped make this a lot easier for me to learn a bit, so thanks for that.
I might play around with what's there, but will try not to break
anything.  ;-)

-- 
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/20051126/8fae2523/attachment.bin