Packaging progress

[Paul W. Frields]

On Wed, 2005-12-28 at 19:27 -0600, Tommy Reynolds wrote:
> Uttered "Paul W. Frields" <stickster at gmail.com>, spake thus:
> > Also, the "fedora-doc-common" RPM is just about ready for rollout and
> > will contain (hopefully) everything required for people not operating
> > out of CVS to build docs.  Mostly this just involves including our XSL
> > snippets, entities, custom scripts, and so forth.  This is not to say
> > that by installing this RPM people will be able to just happily build
> > away, but it puts that goal within reach.
> 
> Yes, necessary precursor step.

And as I write this, that goal is very, VERY close.

[...snip...]
> > I don't know yet what Phase Two entails, but some goals might include:
> >   1. Nice Python scripts for creating new XML document templates
> >   2.   "    "       "    for building DRAFT-marked documents?
> 
> Reasonable.  Why the python focus ;-?  Not that I'm actually against
> it.

See any recent quasi-rant by Seth Vidal on f-devel-l regarding tools for
the platform.

> I would like to see a starter RPM that would explode into a new
> document skeleton and automatically connect to the docs-common RPM. 

No new RPM needed, this will simply be a small script in the docs-common
RPM.

> > Some items I am still in the process of solving, by which I mean I
> > should be able to finish them for Phase One:
> > 
> > - The rpm-info.dtd needs some lovin':
> >   - Packages should not get separate versions, too confusing
> >   - Docs should not get releases, also confusing
> >   - Figure out a way to condense generic person entries for use as
> > authors, editors, translators, and/or packagers?  Alternately, remove
> > those not needed -- e.g. packagers only need full name and email,
> > authors, editors and translators need "component" names, and people
> > performing revisions only need initials.  Some reference to dbpoolx.mod
> > shows this shouldn't be too hard to do.
> 
> Use caution in trying to compress the person stuff.  While the
> minimal information needed varies according to that person's current
> role, the information pool in "rpm-info.xml" is not large, not
> redundant, and not an issue.  Consider if this is over-optimization.
> 
> Take a tip from the RDBMS crowd and collect all the person info into
> a central location (maybe just a <workers>..</workers> set) and then
> use ID linkage to pull the necessary stuff out of that.

I like what you did with the worker stuff.  I am going to change one
small thing to make the option field "#IMPLIED" for othername as I
believe is customary, but it's pretty much 6 of one, half-dozen of
t'other.

> > Provide functionality to automatically sort "doc" or "rpm" revisions.
> > Because RPM is particular about things like date formats in %changelog
> > entries, we may need to "encourage" proper formatting using the DTD.  We
> > already have a *strong* hint there in the attributes Tommy provided, but
> > I don't think there's anything built in to a DTD to check for ordering;
> > I believe, however, that XSLT can sort.  Anything we can do to
> > bulletproof the process is probably good.  If it proves too cumbersome
> > to complete RSN, I'll push this off until Phase Two.
> 
> I considered this, but skipped it because of our current crazy
> numberings.  Besides, with that strong hint, we can just shoot
> whomever screws it up.  Updating the revision info isn't a frequent
> activity and just didn't seem worth the effort until everything else
> was working.

I had an interesting thought about this, which is that rather than
having a "version" and "release" attribute, only one of which is
applicable for each type of revision, why not use a single "revnumber"
attribute?  For docs, this would be a version change, and for new
package rolls it would be a release change.  The latest version for the
doc and the RPM would always be the "revnumber" attribute of the topmost
role="doc" revision, and the RPM's release would always be the
"revnumber" attribute of the topmost role="rpm" revision.

> I wouldn't mind the XSLT doing a lint on the ordering, unless RPM will
> do that later.

I thought the same thing, I'll see what I can do.

The only possible issue I see in the commit you made to rpm-info.dtd
this evening is in requiring copyright holders to be workers.  For
example, Red Hat, Inc. and the Fedora Foundation won't fit that type of
element, although one or both of them will certainly be copyright
holders on several of our works.  If we're not going to keep it as
PCDATA, perhaps using subelements (worker|corp) might work.  I think the
KISS method, though, might dictate punting this one.

-- 
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/20051230/58761995/attachment.bin