[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Advise on Fedora RPM's

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
> 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 n-man com


Attachment: signature.asc
Description: OpenPGP digital signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]