On Fri, 2005-11-18 at 23:57 -0600, Tommy Reynolds wrote:
> Hello Paul, kwade, list, et. al.
>
> I've been struggling with FDP RPM's for a couple of weeks and they
> are not coming together. I think the reason I'm going round and
> round is that I don't have a clear idea of what flavors of RPM's we
> need and what files should be in each. Nor where they should go when
> installed.
>
> I apologize in advance for these ramblings below, but maybe seeing
> them in print will help clarify things. If this doesn't make sense
> to you, feel free to skip the rest of this email.
>
> >From what I can glean from kwade's postings, we should have:
>
> 1) A development RPM that's just a copy of everything that's in the
> CVS tree for a document. I guess this would be the foo.src.rpm
> package. Installing this RPM would instantiate the files in
> /usr/src/redhat or ~/rpm, I guess.
You're correct; that's how SRPMs work in fact. In my testing scheme the
SRPM consists of a tarball of the XML source, the .spec file created
from the common .spec.in, the .desktop file created from the
common .desktop.in, and the .omf file created from the common .omf.in.
> 2) A gnome help package with just the XML files, figures, callouts,
> and the like. I guess this would be a foo.noarch.rpm, similar to
> the RPM's your Makefile changes produce. Installing this RPM
> would populate the /usr/share/fedora/doc tree and drop some
> desktop files in place, too.
Correct, along with the OMF for scrollkeeper, but see below. I think
this file should also contain HTML suitable for (and featuring
prominently in) khelpcenter, as the XML and OMF are for yelp.
> Generating this RPM would actually explode into separate
> foo.en.noarch.rpm or foo.zn_CH.noarch.rpm packages depending on
> the ${LANGUAGES} make(1) macro. Or should all translations stay
> in a single package with per-locale subdirs?
This is an interesting question about namespace... I think it might make
sense for the RPMs to be named "fedora-doc-en-foo-tutorial" since that
would allow people to do "yum install fedora-doc-en\*", which is much
more likely to be helpful than "yum install fedora-doc-\*" which would
give them every doc in every language.
> 3) An RPM containing the formatted HTML/PDF content, suitable for
> browsing and printing. What could this be called? foo.i386.rpm?
> I don't know of a good (standard) place for these files to go at
> install time.
In my opinion these should all be in the .noarch.rpm. Definitely
not .i386 at any rate since they are not arch-specific.
> I've thought about methods to generate the various RPM components,
> such as the .spec files. I found a neat program that lets a shell
> script extract arbitrary content from an XML document:
>
> http://xmlstar.sourceforge.net/
>
> and have gotten it working on FC4. Built an RPM for it so we can add
> it to Fedora Extras if we decide to keep it. Anyway, using this
> program I can write a shell script that will parse the title, author
> info and revision data from the XML document itself or from a
> separate package description file. Built a DTD for that description
> file, too.
I was trying to do this with a Python script, but I don't know enough
about Python, or XML programming therein, to do more than the simplest
things. One reason for my proposals on better entities was to make
simple grep/sed stuff work nicely in the Makefile.
> I ran an experiment where I used the CVS ChangeLog to derive the RPM
> %changelog content, but then realized that the RPM changelog needed
> to reflect the RPM-specific changes, not the day-to-day editing for
> the document itself. OK, I added the RPM change information (not the
> ChangeLog, but manual change data) to the XML package description
> file and then parsed that.
>
> However, it then struck me that if we have to keep the RPM
> package description info in a separate file and maintain it manually,
> then why not just fill out the .spec file directly and have done with
> it.
Now you're starting to feel my pain. ;-) I think the cleanest way to
handle this would be a ChangeLog file in the doc's directory which would
simply be grafted onto the .spec during munging. I think keeping the
majority of the .spec work in a single common file, and "make"-ing it
into the proper form at RPM generation time, is still the Right Thing To
Do. It means that changes in Fedora packaging standards, yelp,
khelpcenter, etc., etc. can be communicated to each doc more easily in
the future.
> Anyone have a clear enough understanding of what the RPM packaging
> should be that they can explain it to a total dunce like me? Perhaps
> you could take one of the more complete documents, such as the
> release notes, and show me the directory hierarchy produced by
> installing each of the RPM types I mentioned above. (Or whatever the
> correct complement of RPM's should be.)
Maybe I should be committing more of my work to CVS to expose the
bruises thus far... :-D
> If you've gotten this far, I'm impressed ;-) Thanks!
--
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/
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-docs-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-docs-list
