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.
+1 on the package type. Location would be /usr/src/redhat. The full
name might be something like 'fedora-doc-install-guide-devel.src.rpm'.
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.
+1 on this package type. Installation of figures, in order to be shared
among formats, might go into a path like
'/usr/share/doc/fedora/install-guide/figs' (with a further path [/en]
for language-specific items) while the XML files would go to
'/usr/share/doc/fedora/install-guide/xml'. The full package name might
be something like 'fedora-doc-install-guide.noarch.rpm'. This lacks any
format extensions as this would be the standard package to install to
access the docs.
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?
I think we should definitely have these broken down into different
packages by locale. Upon installation, the XML documents should go into
eg. /usr/share/doc/fedora/install-guide/xml/en.
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.
These are still architecture-independent, aren't they? Perhaps eg.
'fedora-doc-install-guide-html-en.noarch.rpm'. I know these names might
seem long, but they aren't unprecedented and are necessary to
distinguish these packages. These would install to paths like
/usr/share/doc/fedora/install-guide/html/en.
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.
I think that would largely be a matter of tastes. I'll pass on advising
on this one.
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
There's my $0.02.
--
Patrick "The N-Man" Barnes
nman64(a)n-man.com
www.n-man.com
--