Advise on Fedora RPM's

[Tommy Reynolds]

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.

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.

   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?

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.

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

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

If you've gotten this far, I'm impressed ;-)  Thanks!

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/20051118/810ea1cc/attachment.sig>