Packaging progress

[Tommy Reynolds]

Uttered "Paul W. Frields" <stickster at gmail.com>, spake thus:

> I am steadily making progress toward a packaging solution.  Thanks to
> Tommy jumping in with XSLT-based solutions, I learned a lot (although
> not nearly enough, of course) about how to solve other problems using
> the same building blocks.  I also -- finally! -- figured out how to
> package documentation for KDE's khelpcenter, and believe me, it's not
> self-evident.  Or rather, the end-state is comprehensible, but the
> procedure for getting there cleanly is not.  In any case, that's solved
> too.  

I've seen that fast and furious activity ;-)  Cheers that it is
finally coming together.  Even more, that you have drilled down for
the crufty details for interfacing with those infuriating GUI's.
 
> 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.
 
> Phase One goals are for our currently available documents to be
> installable by an end user using yum, and that those documents
> should show up prominently in each of the locations a user might
> expect:
>   1. Launching "Desktop -> Help" for GNOME or KDE
>   2. Launching "Documentation -> [title]"

Agreed.  Phase One should be getting our Docs and tools in place.

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

I would like to see a starter RPM that would explode into a new
document skeleton and automatically connect to 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.
 
> 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 wouldn't mind the XSLT doing a lint on the ordering, unless RPM will
do that later.

> That's it from my neck of the woods.  Hope everyone is enjoying the
> holidays.  The holiday break and the patience of my ever-lovin' wife are
> the main reason I've been able to work on this stuff for the last few
> days.  Best to all, and here's to a Happy New Year!

Right back at 'cha.

Cheers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-docs-list/attachments/20051228/d929ebae/attachment.sig>