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

[Patrick W. Barnes]

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

[Tommy Reynolds]

Uttered Patrick Barnes , spake thus:
> +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'.

Dude!  Thanks for the magic word "-devel"!  I don't know why I didn't
think of that from the first.  That was the missing piece, at least
for now ;-)

I'm thinking of these RPM's:

<foo>-<version>.src.rpm			Raw CVS dump, w/o CVS subdirs
<foo>-devel-<version>.noarch.rpm	Everything in CVS w/corrected paths
<foo>-<lang>-<version>.noarch.rpm	XML, XSL, images and desktop files

The .src RPM is for archiving purposes, I guess.

The -devel RPM is for folk wishing to use the FDP infrastructure but
not using the CVS facilities.  I'm not sure where the -devel files
should go, but maybe a "pkg-config" crutch would fix this.

The <lang> RPM would hold the XML infrastructure to allow desktop
tools like yelp to work.

Hmm... I'll think about this a bit more.

Thanks!

[Paul W. Frields]

On Sun, 2005-11-20 at 11:21 -0600, Tommy Reynolds wrote:
> Uttered Patrick Barnes , spake thus:
> > +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'.
>
> Dude!  Thanks for the magic word "-devel"!  I don't know why I didn't
> think of that from the first.  That was the missing piece, at least
> for now ;-)
>
> I'm thinking of these RPM's:
>
> <foo>-<version>.src.rpm			Raw CVS dump, w/o CVS subdirs
> <foo>-devel-<version>.noarch.rpm	Everything in CVS w/corrected paths
> <foo>-<lang>-<version>.noarch.rpm	XML, XSL, images and desktop files
>
> The .src RPM is for archiving purposes, I guess.

Umm... Methinks this is kind of missing the point of the .src.rpm.  That
is the source for building; no -devel package containing more of the
same is needed, certainly not on a per-doc basis (see below).  The
original DocBook XML source is in the .src.rpm, probably duplicated
again in the normal .noarch.rpm because yelp uses DocBook XML directly.
Why triplicate this?

The only thing that should be needed for building is
"fedora-doc-common-<ver>.noarch.rpm" (or just call it
"fedora-doc-devel-<ver>.noarch.rpm"), which would contain user scripts
and helpers equivalent to what's in CVS (probably just relocating, as
mentioned above).  Doesn't matter whether its "-common" or "-devel," as
long as it fulfills certain criteria:

- Puts common entities, images, stylesheets and so forth in a place
where they are available not just for the user building docs, but also
where they can be accessed for use in yelp, khelpcenter, etc.
- Includes scripts that allow documents to be built from XML source
already written to /usr/share/fedora/doc/ (or wherever is referenced
in /usr/share/omf/<docname>/<locale> as part of
fedora-doc-<lang>-<ver>.noarch.rpm
- Proper Requires: on any stuff we're currently using (e.g. xmlformat)
that needs to also be in Extras or Core

If we need to change scripts, Makefiles, and such to make them
universally adaptable not just in CVS but in their packaged form, let's
do that.  Better that than having to maintain two sets of scripts and
build environments.  Is there a good reason *not* to do so (you know,
other than "gee, that sounds hard")?
> The -devel RPM is for folk wishing to use the FDP infrastructure but
> not using the CVS facilities.  I'm not sure where the -devel files
> should go, but maybe a "pkg-config" crutch would fix this.

There's really no reason they couldn't live in /usr/share/fedora/
somwhere, which is the right place for them given the namespacing the
rest of the Fedora Project is using.
> The <lang> RPM would hold the XML infrastructure to allow desktop
> tools like yelp to work.

Right, which is why a separate -devel per doc is probably not that
useful.  With a proper extra doc on "How to Build Docs," itself included
in yelp/khelpcenter as part of the fedora-doc-[common|devel] package,
people should be able to "fedoradoc-make" a doc, or something like that,
to build things we've included, or their own docs.  Perhaps such a
helper would also include relevant checks for project standards.
> Hmm... I'll think about this a bit more.
>
> Thanks!

I realized that having a <lang> RPM implies we should have separate
<lang> .desktop files for each package.  Just a note for the archive for
later...

[Tommy Reynolds]

Uttered "Paul W. Frields" , spake thus:
> On Sun, 2005-11-20 at 11:21 -0600, Tommy Reynolds wrote:
> > Uttered Patrick Barnes , spake thus:
> > > +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'.
> >
> > I'm thinking of these RPM's:
> > <foo>-<version>.src.rpm		Raw CVS dump, w/o CVS subdirs
> > <foo>-devel-<version>.noarch.rpm	Everything in CVS w/corrected paths
> > <foo>-<lang>-<version>.noarch.rpm	XML, XSL, images and desktop files
> > The .src RPM is for archiving purposes, I guess.
>
> Umm... Methinks this is kind of missing the point of the .src.rpm.
> Why triplicate this?

Ouch.  OK, I see the light.
> The only thing that should be needed for building is
> "fedora-doc-common-<ver>.noarch.rpm" which would contain user
> scripts and helpers equivalent to what's in CVS (probably just
> relocating, as mentioned above).

Recently I put the line "sinclude Make.paths" into "Makefile.common"
to deal with the relocations for RPM installation.  The idea is that
the docs-common package is a prerequisite to everything else.  As all
other packages get installed, a "%post" line does something like this:

%post
echo $(dirname $(rpm -ql docs-common | grep Makefile.common)) \
    >/path/to/example-tutorial/Make.paths

and then:

%pre
rm -f /path/to/example-tutorial/Make.paths

to close the loop.  I'll probably need to use a pkg-config crutch
because we'll still need to correct the paths embedded in the XML,
XSL and Makefiles.
> Is there a good reason *not* to do so (you know, other than "gee,
> that sounds hard")?

Not as long as you are doing the hard part ;-)
> > The -devel RPM is for folk wishing to use the FDP infrastructure but
> > not using the CVS facilities.  I'm not sure where the -devel files
> > should go, but maybe a "pkg-config" crutch would fix this.
>
> There's really no reason they couldn't live in /usr/share/fedora/
> somwhere, which is the right place for them given the namespacing the
> rest of the Fedora Project is using.

Fine with me.
> > The <lang> RPM would hold the XML infrastructure to allow desktop
> > tools like yelp to work.
>
> Right, which is why a separate -devel per doc is probably not that
> useful.  With a proper extra doc on "How to Build Docs," itself included
> in yelp/khelpcenter as part of the fedora-doc-[common|devel] package,
> people should be able to "fedoradoc-make" a doc, or something like that,
> to build things we've included, or their own docs.  Perhaps such a
> helper would also include relevant checks for project standards.

Yeah, that would work.  The docs-common package could drop stuff in a
"/usr/share/fedora/build" directory or the like.
> I realized that having a <lang> RPM implies we should have separate
> <lang> .desktop files for each package.  Just a note for the archive for
> later...

Er, no.  The .desktop files allow constructs like "Name[de]=Handheld
PDA" and "Name[es]=PDA de mano" and avoid all this cruft.  This
argues for either a real .desktop file that translators maintain or
the XML-style build info file I mentioned earlier.

==[/home/reynolds/src/f/fedora-docs/docs-common/rpm-info.dtd]==

<!--
  DTD for the Fedora Docs Project RPM Information file "rpm-info.xml"
-->

<!ELEMENT 	rpm-info 	(titles,changelog) 		>

<!ELEMENT 	titles	 	(translation+) 			>

<!ELEMENT	translation	(title,desc)*			>
<!ATTLIST	translation lang CDATA		#REQUIRED	>

<!ELEMENT	title		(#PCDATA)			>
<!ELEMENT	desc		(#PCDATA)			>

<!ELEMENT	changelog	(revision+)			>

<!ELEMENT	revision	(date,author,details)		>

<!ELEMENT	date		EMPTY				>
<!ATTLIST	date	year	CDATA		#REQUIRED	>
<!ATTLIST	date	month	CDATA		#REQUIRED	>
<!ATTLIST	date	day	CDATA		#REQUIRED	>
<!ATTLIST	date	dname	CDATA		#REQUIRED	>

<!ELEMENT	author		EMPTY				>
<!ATTLIST	author	name	CDATA		#REQUIRED	>
<!ATTLIST	author	email	CDATA		#REQUIRED	>

<!ELEMENT	details		(#PCDATA)			>

==[/home/reynolds/src/f/fedora-docs/docs-common/rpm-info.xml]==

<?xml version="1.0" encoding="UTF-8"?>

<!-- Sample document description from which we build RPMs -->

<!DOCTYPE rpm-info SYSTEM "rpm-info.dtd">
<rpm-info>
  <titles>
    <translation lang="en">
      <title>Example Tutorial</title>
      <desc>This is quite a feat.</desc>
    </translation>
    <translation lang="de">
      <title>Beispeil Tutorial</title>
      <desc>Ist idiotien</desc>
    </translation>
  </titles>
  <changelog>
    <revision>
      <date day="08" dname="Tue" month="11" year="2005"/>
      <author email="[e-mail]" name="Tommy Reynolds"/>
      <details>Just noodling with the files...</details>
    </revision>
  </changelog>
</rpm-info>

==[END]==

What 'cha think?

[Paul W. Frields]

On Sun, 2005-11-20 at 14:14 -0600, Tommy Reynolds wrote:
> Uttered "Paul W. Frields" , spake thus:
> > The only thing that should be needed for building is
> > "fedora-doc-common-<ver>.noarch.rpm" which would contain user
> > scripts and helpers equivalent to what's in CVS (probably just
> > relocating, as mentioned above).
>
> Recently I put the line "sinclude Make.paths" into "Makefile.common"
> to deal with the relocations for RPM installation.  The idea is that
> the docs-common package is a prerequisite to everything else.  As all
> other packages get installed, a "%post" line does something like this:
>
> %post
> echo $(dirname $(rpm -ql docs-common | grep Makefile.common)) \
> > /path/to/example-tutorial/Make.paths
>
> and then:
>
> %pre
> rm -f /path/to/example-tutorial/Make.paths
>
> to close the loop.  I'll probably need to use a pkg-config crutch
> because we'll still need to correct the paths embedded in the XML,
> XSL and Makefiles.

Just in the FC/FE spirit of "don't use %pre/%post unless you have to,"
could the Make.paths file simply be built at RPM building time?  I was
under the impression that playing around with RPM queries during an RPM
installation/erase process is not a desirable thing.  I think I
understand why we want the file, I'm just guessing we can probably build
the file during "make rpm" and simply list it in the %files per normal.
> > Is there a good reason *not* to do so (you know, other than "gee,
> > that sounds hard")?
>
> Not as long as you are doing the hard part ;-)

And *that* is why I don't live in a commune.  (OK, that's not the only
reason why.)  Q.v. etymology for community, no?  ;-D
> > > The -devel RPM is for folk wishing to use the FDP infrastructure but
> > > not using the CVS facilities.  I'm not sure where the -devel files
> > > should go, but maybe a "pkg-config" crutch would fix this.
> >
> > There's really no reason they couldn't live in /usr/share/fedora/
> > somwhere, which is the right place for them given the namespacing the
> > rest of the Fedora Project is using.
>
> Fine with me.

Ah, sweet consensus!
> > > The <lang> RPM would hold the XML infrastructure to allow desktop
> > > tools like yelp to work.
> >
> > Right, which is why a separate -devel per doc is probably not that
> > useful.  With a proper extra doc on "How to Build Docs," itself included
> > in yelp/khelpcenter as part of the fedora-doc-[common|devel] package,
> > people should be able to "fedoradoc-make" a doc, or something like that,
> > to build things we've included, or their own docs.  Perhaps such a
> > helper would also include relevant checks for project standards.
>
> Yeah, that would work.  The docs-common package could drop stuff in a
> "/usr/share/fedora/build" directory or the like.

Disco!
> > I realized that having a <lang> RPM implies we should have separate
> > <lang> .desktop files for each package.  Just a note for the archive for
> > later...
>
> Er, no.  The .desktop files allow constructs like "Name[de]=Handheld
> PDA" and "Name[es]=PDA de mano" and avoid all this cruft.  This
> argues for either a real .desktop file that translators maintain or
> the XML-style build info file I mentioned earlier.
>
> ==[/home/reynolds/src/f/fedora-docs/docs-common/rpm-info.dtd]==
>
> <!--
>   DTD for the Fedora Docs Project RPM Information file "rpm-info.xml"
> -->
>
> <!ELEMENT 	rpm-info 	(titles,changelog) 		>
>
> <!ELEMENT 	titles	 	(translation+) 			>
>
> <!ELEMENT	translation	(title,desc)*			>
>
> <!ATTLIST	translation lang CDATA		#REQUIRED	>
>
> <!ELEMENT	title		(#PCDATA)			>
>
> <!ELEMENT	desc		(#PCDATA)			>
>
> <!ELEMENT	changelog	(revision+)			>
>
> <!ELEMENT	revision	(date,author,details)		>
>
> <!ELEMENT	date		EMPTY				>
>
> <!ATTLIST	date	year	CDATA		#REQUIRED	>
>
> <!ATTLIST	date	month	CDATA		#REQUIRED	>
>
> <!ATTLIST	date	day	CDATA		#REQUIRED	>
>
> <!ATTLIST	date	dname	CDATA		#REQUIRED	>
>
> <!ELEMENT	author		EMPTY				>
>
> <!ATTLIST	author	name	CDATA		#REQUIRED	>
>
> <!ATTLIST	author	email	CDATA		#REQUIRED	>
>
> <!ELEMENT	details		(#PCDATA)			>
>
> ==[/home/reynolds/src/f/fedora-docs/docs-common/rpm-info.xml]==
>
> <?xml version="1.0" encoding="UTF-8"?>
>
> <!-- Sample document description from which we build RPMs -->
>
> <!DOCTYPE rpm-info SYSTEM "rpm-info.dtd">
>
> <rpm-info>
>   <titles>
>     <translation lang="en">
>       <title>Example Tutorial</title>
>       <desc>This is quite a feat.</desc>
>     </translation>
>     <translation lang="de">
>       <title>Beispeil Tutorial</title>
>       <desc>Ist idiotien</desc>
>     </translation>
>   </titles>
>   <changelog>
>     <revision>
>       <date day="08" dname="Tue" month="11" year="2005"/>
>       <author email="[e-mail]" name="Tommy Reynolds"/>
>       <details>Just noodling with the files...</details>
>     </revision>
>   </changelog>
> </rpm-info>
>
> ==[END]==
>
> What 'cha think?

That's totally bitchin AFAIC.  But the point I was trying to make is
that if there is a separate .noarch.rpm for each <lang>, each one needs
its own .desktop file.  The alternatives AIUI are:

- a foo-<lang>.desktop file in a single foo-<lang>.noarch.rpm RPM will
have all the translations for the name of the shortcut, but will lead to
a single language version of the document, which confuses the user, who
expects to see the doc for his language come up when he clicks on the
menu item

- an identical foo.desktop file for every foo-<lang>.noarch.rpm, meaning
you get yucky RPM conflicts

So to me, the best solution is a foo-<lang>.desktop file that contains
only <lang>-specific name, etc.  They could still come out of the
(totally bitchin) XML but would act as expected.  The shortcuts would
read in the native language, so I could install the foo-de.noarch.rpm
and click on the "Foo (Deutsch)" menu item to read the German version,
supposedly to check the translation for errors if I'm bilingual.

Am I making any sense?  All this is independent of the bitchin-ness of
your XML stuff, which will be useful no matter which way the .desktop
thing goes.

[Ignacio Vazquez-Abrams]

On Fri, 2005-11-18 at 23:57 -0600, Tommy Reynolds wrote:
> 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.

An export of the CVS tree, yes.
> 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.

Sounds good.
> 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?

The latter. It doesn't matter if the SRPM ends up being hundreds of
megabytes as one shouldn't need it other than in exceptional
circumstances.
> 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.

HTML and PDF are arch-independent so they would be noarch. And they
should go in the standard doc location, i.e., /usr/share/doc.
> 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.

https://www.redhat.com/archives/fedora-extras-list/2005-July/msg00591.html
The thread explains why it's not in yet. Summary: ambiguous command
name.
> 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 can walk me through handling the stuff in CVS, possibly in
#fedora-docs, then I can take a look at it.

[Patrick W. Barnes]

Ignacio Vazquez-Abrams wrote:
> On Fri, 2005-11-18 at 23:57 -0600, Tommy Reynolds wrote:
> > 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?
>
> The latter. It doesn't matter if the SRPM ends up being hundreds of
> megabytes as one shouldn't need it other than in exceptional
> circumstances.

The SRPM can contain all languages and be as large as it needs to be,
but the RPMs built from it should be broken down into the different locales.

[Ignacio Vazquez-Abrams]

On Sat, 2005-11-19 at 12:42 -0600, Patrick Barnes wrote:
> Ignacio Vazquez-Abrams wrote:
> > On Fri, 2005-11-18 at 23:57 -0600, Tommy Reynolds wrote:
> > > 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?
> >
> > The latter. It doesn't matter if the SRPM ends up being hundreds of
> > megabytes as one shouldn't need it other than in exceptional
> > circumstances.
>
> The SRPM can contain all languages and be as large as it needs to be,
> but the RPMs built from it should be broken down into the different locales.

Right, I misread the question, sorry.

[Paul W. Frields]

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

OK, I spent a few hours this morning banging my head against the problem
(again), trying to mentally clarify additional issues.  There may be
significant opinion mixed with fact here, be wary...  Maybe this is just
more food for thought?

1.  We should have separate .noarch.rpm ("binary" RPM) packages for each
language.  Although the scrollkeeper/yelp and khelpcenter parts are
mostly XML and HTML files that simply don't take up much space, the
screenshots for things like the Installation Guide and other upcoming
works are going to drastically increase the size of these packages.  No
reason to burden all users with i18n they can't use.

The easiest way to do this is with subpackages in the .spec.in.common,
but that puts the namespacing as "fedora-doc-docname-en-0.14" instead of
"fedora-doc-en-docname-0.14".  Does it put a significant burden on the
user if "installing all docs for my LANG" means "yum install
fedora-doc-*-LANG" instead of "yum install fedora-doc-LANG-*"?  Should
we figure out how to do this with yum groups instead, having a
"Documentation/English," "Documentation/Italian," etc.?  Is such a thing
possible while *NOT* putting a burden on Core development to support
this confusion?

2.  To a significant extent, SRPMs will have duplicative content with
the RPMs; this is unavoidable and not really a problem /per se/.  There
shouldn't be any HTML in the SRPMs, just the DocBook-XML originals,
screenshots, etc.

3.  I've done the RPM building process about three different ways thus
far, none of them great, and each of them confusing in a unique way.  I
am going to try to flowchart something out to make the process a little
clearer to myself before I try again.  I keep getting hung up on when to
set up i18n templates and when not.  What makes this challenging is that
in order to make the process work, the OMFs, the specfile, and the
various tarballs must be coordinated in a pretty interesting little
ballet.  Back to the grindstone...

[Tommy Reynolds]

Uttered "Paul W. Frields" , spake thus:
> We should have separate .noarch.rpm ("binary" RPM) packages for each
>
> language.

Yup, I agree.  See my reply to the nman's post mentioning that
wonderful phrase "-devel".
> The easiest way to do this is with subpackages in the .spec.in.common,
> but that puts the namespacing as "fedora-doc-docname-en-0.14" instead of
> "fedora-doc-en-docname-0.14".

Well, the "fedora-doc-docname-en" form is what seemed most obvious to
me from the beginning.
> Does it put a significant burden on the user if "installing all
> docs for my LANG" means "yum install fedora-doc-*-LANG" instead of
> "yum install fedora-doc-LANG-*"?  Should we figure out how to do
> this with yum groups instead, having a "Documentation/English,"
> "Documentation/Italian," etc.?  Is such a thing possible while
> *NOT* putting a burden on Core development to support this
> confusion?

If folk need type the silly wildcard, then it should not make much
difference where it goes.

I can't find precedent for this approach, though.  Can you point to
a package set using the "foo-<lang>-*" template?

About the "Documentation/<lang>" groups, I don't know.  I'm intrigued
though, so I'll look at the anaconda stuff to see what needs to be
done.
> To a significant extent, SRPMs will have duplicative content with
>
> the RPMs; this is unavoidable and not really a problem /per se/.  There
> shouldn't be any HTML in the SRPMs, just the DocBook-XML originals,
> screenshots, etc.

Agree.
> I've done the RPM building process about three different ways thus
>
> far, none of them great, and each of them confusing in a unique way.

Yeah.  Think twice, code once ;-)

Perhaps a question will help focus the discussion:  Who builds /
maintains the RPM overhead files, such as the OMF and SPEC files?

Granted there are significant portions of each we could treat as
boilerplate, some content (such as translations of the package name)
must come from the translators themselves.

So, my question is really "originate or derive?"

If we originate, it should not be a burden for the first doc author
to copy a prototype "foo.spec" from "docs-common/packaging" and edit
for the package name, description and to maintain the %changelog.
Translators can then just add (or maybe just uncomment) a couple of
lines for each translation.  With this approach, RPM packaging is
much simpler.

On the other hand, if we derive, then authors and translators will
still need to supply the localized doc names and descriptions.  We
should be able to derive most of the stuff from the XML-format OMF
file, given a suitable XML tool like the "xmlstar*" program I found.
Have the author team edit the OMF file and then pick stuff out of
that. (Question: is there a DTD for the OMF file?)

I don't consider having the author team maintain one overhead file for
RPM generation much of a burden.

Let's agree on what we want to do before everyone roars off and
invents the wheel.  Of course, we'll need a bit of trial and error
before we decide what it is that we want to do...

Cheers!

* [footnote]
Someone pointed out that the Fedora Extras folk have been discussing
the xmlstar tool but so far have avoided in because of the "ambiguous
package name".  Even its author uses at least three different names
for it on the web pages.  With the power of an RPM patch file, we can
include the tool using any name we like.  With proper attribution in
the SPEC file, we can name it anything we like.  No huhu.

[Paul W. Frields]

On Sun, 2005-11-20 at 11:53 -0600, Tommy Reynolds wrote:
> Uttered "Paul W. Frields" , spake thus:
> > The easiest way to do this is with subpackages in the .spec.in.common,
> > but that puts the namespacing as "fedora-doc-docname-en-0.14" instead of
> > "fedora-doc-en-docname-0.14".
>
> Well, the "fedora-doc-docname-en" form is what seemed most obvious to
> me from the beginning.

'S cool, I can go either way with this.
> > Does it put a significant burden on the user if "installing all
> > docs for my LANG" means "yum install fedora-doc-*-LANG" instead of
> > "yum install fedora-doc-LANG-*"?  Should we figure out how to do
> > this with yum groups instead, having a "Documentation/English,"
> > "Documentation/Italian," etc.?  Is such a thing possible while
> > *NOT* putting a burden on Core development to support this
> > confusion?
>
> If folk need type the silly wildcard, then it should not make much
> difference where it goes.
>
> I can't find precedent for this approach, though.  Can you point to
> a package set using the "foo-<lang>-*" template?

Ahh, yes.  See e.g. koffice-langpack-* in Extras I think.  I haven't
looked at the SRPM yet.
> About the "Documentation/<lang>" groups, I don't know.  I'm intrigued
> though, so I'll look at the anaconda stuff to see what needs to be
> done.

I thought this was underway in Anaconda, but doesn't even that revolve
around comps?
> > To a significant extent, SRPMs will have duplicative content with
> >
> > the RPMs; this is unavoidable and not really a problem /per se/.  There
> > shouldn't be any HTML in the SRPMs, just the DocBook-XML originals,
> > screenshots, etc.
>
> Agree.
> > I've done the RPM building process about three different ways thus
> >
> > far, none of them great, and each of them confusing in a unique way.
>
> Yeah.  Think twice, code once ;-)

Actually that proportion was about right. :-D
> Perhaps a question will help focus the discussion:  Who builds /
> maintains the RPM overhead files, such as the OMF and SPEC files?

I think we should handle this in docs-common to the greatest possible
extent.
> Granted there are significant portions of each we could treat as
> boilerplate, some content (such as translations of the package name)
> must come from the translators themselves.
>
> So, my question is really "originate or derive?"
>
> If we originate, it should not be a burden for the first doc author
> to copy a prototype "foo.spec" from "docs-common/packaging" and edit
> for the package name, description and to maintain the %changelog.
> Translators can then just add (or maybe just uncomment) a couple of
> lines for each translation.  With this approach, RPM packaging is
> much simpler.
>
> On the other hand, if we derive, then authors and translators will
> still need to supply the localized doc names and descriptions.  We
> should be able to derive most of the stuff from the XML-format OMF
> file, given a suitable XML tool like the "xmlstar*" program I found.
> Have the author team edit the OMF file and then pick stuff out of
> that. (Question: is there a DTD for the OMF file?)
>
> I don't consider having the author team maintain one overhead file for
> RPM generation much of a burden.

Agreed there.  I think it would be cool if we simply required one extra
file, an XML one based on the DTD you provided.  All authors and
translators could update that, and everything needed to press the spec,
OMF, .desktop, etc. would come out of that file at build time.
> Let's agree on what we want to do before everyone roars off and
> invents the wheel.  Of course, we'll need a bit of trial and error
> before we decide what it is that we want to do...
>
> Cheers!

Agreed.
> [footnote]
>
> Someone pointed out that the Fedora Extras folk have been discussing
> the xmlstar tool but so far have avoided in because of the "ambiguous
> package name".  Even its author uses at least three different names
> for it on the web pages.  With the power of an RPM patch file, we can
> include the tool using any name we like.  With proper attribution in
> the SPEC file, we can name it anything we like.  No huhu.

It looks like from the discussion you referenced that the original
packager has dropped out of the running.  Shall I email him and see if
he minds me picking up the package instead?  I don't mind patching it
and getting it into FE if it will help us move down this road by the
time of FC5t2 or t3.

[Tommy Reynolds]

Uttered "Paul W. Frields" , spake thus:
> > I can't find precedent for this approach, though.  Can you point to
> > a package set using the "foo-<lang>-*" template?
>
> Ahh, yes.  See e.g. koffice-langpack-* in Extras I think.  I haven't
> looked at the SRPM yet.

NOT COUNTING KDE!! I'm kidding.  Maybe that should be "I'm kdeing" ;-)
> > About the "Documentation/<lang>" groups, I don't know.  I'm intrigued
> > though, so I'll look at the anaconda stuff to see what needs to be
> > done.
>
> I thought this was underway in Anaconda, but doesn't even that revolve
> around comps?

Dunno.  I'm looking.
> > I don't consider having the author team maintain one overhead file for
> > RPM generation much of a burden.
>
> Agreed there.  I think it would be cool if we simply required one extra
> file, an XML one based on the DTD you provided.  All authors and
> translators could update that, and everything needed to press the spec,
> OMF, .desktop, etc. would come out of that file at build time.

If you can send me the prototype OMF, et.al., I may find time to
produce some XSL stylesheets to do the necessary transformation from
the funky XML info file into an OMF or a SPEC and be able to eschew
any additions to Fedora Extras.

Cheers

[Paul W. Frields]

On Sun, 2005-11-20 at 18:21 -0600, Tommy Reynolds wrote:
> Uttered "Paul W. Frields" , spake thus:
> > > I can't find precedent for this approach, though.  Can you point to
> > > a package set using the "foo-<lang>-*" template?
> >
> > Ahh, yes.  See e.g. koffice-langpack-* in Extras I think.  I haven't
> > looked at the SRPM yet.
>
> NOT COUNTING KDE!! I'm kidding.  Maybe that should be "I'm kdeing" ;-)
> > > About the "Documentation/<lang>" groups, I don't know.  I'm intrigued
> > > though, so I'll look at the anaconda stuff to see what needs to be
> > > done.
> >
> > I thought this was underway in Anaconda, but doesn't even that revolve
> > around comps?
>
> Dunno.  I'm looking.
> > > I don't consider having the author team maintain one overhead file for
> > > RPM generation much of a burden.
> >
> > Agreed there.  I think it would be cool if we simply required one extra
> > file, an XML one based on the DTD you provided.  All authors and
> > translators could update that, and everything needed to press the spec,
> > OMF, .desktop, etc. would come out of that file at build time.
>
> If you can send me the prototype OMF, et.al., I may find time to
> produce some XSL stylesheets to do the necessary transformation from
> the funky XML info file into an OMF or a SPEC and be able to eschew
> any additions to Fedora Extras.

You'll find the prototype OMF in docs-common/packaging,  It is ugly in
that it only really works for "en" $LANG.  What you'll find is that OMFs
are separately constructed for each locale and placed
in /usr/share/omf/<doc_or_prog_name>,
e.g. /usr/share/omf/gcalctool/gcalctool-it.omf -- the "C" locale is used
for en.  (That goes for at least en.UTF-8, maybe other sub-locales -- or
whatever you call them, I'm out of my depth there.)

The OMF standard is discussed
in /usr/share/scrollkeeper/doc/writing_scrollkeeper_omf_files/C/writing_scrollkeeper_omf_files.xml if you want to take a look at the real authoritative stuff -- or in GNOME, just launch Desktop -> Help -> Writing Scrollkeeper OMF Files.

(Just a side note:  One thing we *definitely* want is for all official
FDP docs to be in the General|Linux|Distributions|Other category, since
that will put them on the front "Help" page where people find them
quickly.  You'll see that in the example in docs-common/packaging/.)

If you run "make rpm" in the docs-common/ module, you'll get my first
cut at what a fedora-doc-common RPM would look like.  Notice it includes
things like a .menu file for the /etc/xdg/ tree so that later docs will
show up on the Applications -> Documentation menu as well as yelp,
khelpcenter, or anywhere else we decide.  The .desktop files are set up
to allow such a thing.  Let me know if there's anything there that looks
wacko.

xmlstarlet (was: Re: Advise on Fedora RPM's)

[Ignacio Vazquez-Abrams]

On Sun, 2005-11-20 at 17:21 -0500, Paul W. Frields wrote:
> > [footnote]
> >
> > Someone pointed out that the Fedora Extras folk have been discussing
> > the xmlstar tool but so far have avoided in because of the "ambiguous
> > package name".  Even its author uses at least three different names
> > for it on the web pages.  With the power of an RPM patch file, we can
> > include the tool using any name we like.  With proper attribution in
> > the SPEC file, we can name it anything we like.  No huhu.
>
> It looks like from the discussion you referenced that the original
> packager has dropped out of the running.  Shall I email him and see if
> he minds me picking up the package instead?  I don't mind patching it
> and getting it into FE if it will help us move down this road by the
> time of FC5t2 or t3.

I wouldn't say I've "dropped out"; I haven't heard from upstream and
have been too busy to deal with it. If you want it then by all means
take it.

Also, it wasn't the package name but the binary name. "xml" was
designated to be too generic. I did have a patch for it IIRC; let me
look around.

xmlstarlet (was: Re: Advise on Fedora RPM's)

[Paul W. Frields]

On Sun, 2005-11-20 at 21:53 -0500, Ignacio Vazquez-Abrams wrote:
> On Sun, 2005-11-20 at 17:21 -0500, Paul W. Frields wrote:
> > > [footnote]
> > >
> > > Someone pointed out that the Fedora Extras folk have been discussing
> > > the xmlstar tool but so far have avoided in because of the "ambiguous
> > > package name".  Even its author uses at least three different names
> > > for it on the web pages.  With the power of an RPM patch file, we can
> > > include the tool using any name we like.  With proper attribution in
> > > the SPEC file, we can name it anything we like.  No huhu.
> >
> > It looks like from the discussion you referenced that the original
> > packager has dropped out of the running.  Shall I email him and see if
> > he minds me picking up the package instead?  I don't mind patching it
> > and getting it into FE if it will help us move down this road by the
> > time of FC5t2 or t3.
>
> I wouldn't say I've "dropped out"; I haven't heard from upstream and
> have been too busy to deal with it. If you want it then by all means
> take it.

Pardon my poor choice of words -- was in a hasty rush to make the kids
some dinner. :-)  I meant "withdrawn the package for now."  We are
really interested in this package, so if you don't have time to do it we
(by which I mean "I," at least as far as this package goes) would be
happy to help, and you have our thanks for bringing it up to this
point.
> Also, it wasn't the package name but the binary name. "xml" was
> designated to be too generic. I did have a patch for it IIRC; let me
> look around.

If you thought you'd have to time *review* the package for Extras that
would probably be a huge help!  Thanks Ignacio!

xmlstarlet (was: Re: Advise on Fedora RPM's)

[Tommy Reynolds]

Uttered "Paul W. Frields" , spake thus:
> On Sun, 2005-11-20 at 21:53 -0500, Ignacio Vazquez-Abrams wrote:
> > On Sun, 2005-11-20 at 17:21 -0500, Paul W. Frields wrote:
> > > > Someone pointed out that the Fedora Extras folk have been discussing
> > > > the xmlstar tool but so far have avoided in because of the "ambiguous
> > > > package name".
> > >
> > > It looks like from the discussion you referenced that the original
> > > packager has dropped out of the running.  Shall I email him and see if
> > > he minds me picking up the package instead?  I don't mind patching it
> > > and getting it into FE if it will help us move down this road by the
> > > time of FC5t2 or t3.
> >
> > I wouldn't say I've "dropped out"; I haven't heard from upstream and
> > have been too busy to deal with it. If you want it then by all means
> > take it.
>
> We are really interested in this package, so if you don't have time
> to do it we (by which I mean "I," at least as far as this package
> goes) would be happy to help, and you have our thanks for bringing
> it up to this point.
> > Also, it wasn't the package name but the binary name. "xml" was
> > designated to be too generic. I did have a patch for it IIRC; let me
> > look around.
>
> If you thought you'd have to time *review* the package for Extras that
> would probably be a huge help!  Thanks Ignacio!

As I mentioned in my original post, I have the package patched and an
RPM built if you'd like to review it.

Cheers

xmlstarlet (was: Re: Advise on Fedora RPM's)

[Paul W. Frields]

On Mon, 2005-11-21 at 09:29 -0600, Tommy Reynolds wrote:
> Uttered "Paul W. Frields" , spake thus:
> > On Sun, 2005-11-20 at 21:53 -0500, Ignacio Vazquez-Abrams wrote:
> > > Also, it wasn't the package name but the binary name. "xml" was
> > > designated to be too generic. I did have a patch for it IIRC; let me
> > > look around.
> >
> > If you thought you'd have to time *review* the package for Extras that
> > would probably be a huge help!  Thanks Ignacio!
>
> As I mentioned in my original post, I have the package patched and an
> RPM built if you'd like to review it.

Superb, bring it on!

xmlstarlet (was: Re: Advise on Fedora RPM's)

[Tommy Reynolds]

Uttered "Paul W. Frields" , spake thus:
> > As I mentioned in my original post, I have the package patched and an
> > RPM built if you'd like to review it.
>
> Superb, bring it on!

OK.  I've put it here:

http://www.megacoder.com/pub/xmlstarlet/
    ftp://ftp.megacoder.com/pub/xmlstarlet/

It renames the "xml" application to "xmlstarlet" to match the package
name, the documentation, the web page...

Just for fun, here is an XSLT stylesheet that shows we can derive the
<bookinfo> stuff, as well as the OMF and SPEC file stuff.  Run it
like this:

$ xsltproc rpm-info.xsl rpm-info.xml

using the files I posted yesterday.

Have fun with it!

==[/home/reynolds/src/f/fedora-docs/docs-common/rpm-info.xsl]==
<xsl:stylesheet version="1.0" xml:space="preserve" xmlns:xsl="http://www.w3.org/1999/XSL/Transform%22%3E

<!-- Note: do not indent this file!  Any whitespace here
     will be reproduced in the output -->

<xsl:template match="/">
<xsl:apply-templates select="rpm-info"/>
</xsl:template>

<xsl:template match="rpm-info">
<xsl:apply-templates select="titles"/>
</xsl:template>

<xsl:template match="titles">
Processing titles
<xsl:apply-templates select="*|node()"/>
</xsl:template>

<xsl:template match="translation">
Processing translation (<xsl:value-of select="@lang"/>)
<xsl:apply-templates select="*|node()"/>
</xsl:template>

<xsl:template match="title">
Processing title
<xsl:apply-templates select="*|node()"/>
</xsl:template>

<xsl:template match="desc">
Processing desc
<xsl:apply-templates select="*|node()"/>
</xsl:template>

<xsl:template match="changelog">
xsl:text%changelog</xsl:text>
<xsl:apply-templates select="*|node()"/>
</xsl:template>

<xsl:template match="revision">
Processing revision
<xsl:apply-templates select="*|node()"/>
</xsl:template>

<xsl:template match="date">
Processing date
<xsl:apply-templates select="*|node()"/>
</xsl:template>

<xsl:template match="author">
Processing author
<xsl:apply-templates select="*|node()"/>
</xsl:template>

<xsl:template match="details">
Processing details
<xsl:apply-templates select="*|node()"/>
</xsl:template>

</xsl:stylesheet>

===[EOF]===

Cheers

xmlstarlet (was: Re: Advise on Fedora RPM's)

[Paul W. Frields]

On Mon, 2005-11-21 at 12:41 -0600, Tommy Reynolds wrote:
> Uttered "Paul W. Frields" , spake thus:
> > > As I mentioned in my original post, I have the package patched and an
> > > RPM built if you'd like to review it.
> >
> > Superb, bring it on!
>
> OK.  I've put it here:
>
> http://www.megacoder.com/pub/xmlstarlet/
>    ftp://ftp.megacoder.com/pub/xmlstarlet/

Do you have the .src.rpm available?

xmlstarlet (was: Re: Advise on Fedora RPM's)

[Tommy Reynolds]

Uttered "Paul W. Frields" , spake thus:
> > http://www.megacoder.com/pub/xmlstarlet/
> >    ftp://ftp.megacoder.com/pub/xmlstarlet/
>
> Do you have the .src.rpm available?

Yup; it's there now.

Sorry, too big of a hurry.

xmlstarlet (was: Re: Advise on Fedora RPM's)

[Paul W. Frields]

On Tue, 2005-11-22 at 07:40 -0600, Tommy Reynolds wrote:
> Uttered "Paul W. Frields" , spake thus:
> > > http://www.megacoder.com/pub/xmlstarlet/
> > >    ftp://ftp.megacoder.com/pub/xmlstarlet/
> >
> > Do you have the .src.rpm available?
>
> Yup; it's there now.

Thanks Tommy, and Ignacio too for that matter.  This is now in the FE
queue.  If one of you is a FE reviewer, it would be great if you could
take it upon yourselves to verify that all the concerns have been
handled.  I have no doubt Tommy's done that, and I think the .spec
buffed to a high "FE" gloss, so it should be a quick process.  See the
BZ entry:

https://bugzilla.redhat.com/173924

xmlstarlet (was: Re: Advise on Fedora RPM's)

[Tommy Reynolds]

Uttered "Paul W. Frields" , spake thus:
> > > > ftp://ftp.megacoder.com/pub/xmlstarlet/
> > >
> > > Do you have the .src.rpm available?
> >
> > Yup; it's there now.
>
> Thanks Tommy, and Ignacio too for that matter.  This is now in the FE
> queue.  If one of you is a FE reviewer, it would be great if you could
> take it upon yourselves to verify that all the concerns have been
> handled.  I have no doubt Tommy's done that, and I think the .spec
> buffed to a high "FE" gloss, so it should be a quick process.  See the
> BZ entry:
> https://bugzilla.redhat.com/173924

Oops!  The RPM contains the *patched* sources, instead of the
pristine sources and a patch.

Give me a couple of minutes, and I'll fix it.

Cheers

xmlstarlet (was: Re: Advise on Fedora RPM's)

[Paul W. Frields]

On Tue, 2005-11-22 at 13:38 -0600, Tommy Reynolds wrote:
> Uttered "Paul W. Frields" , spake thus:
> > > > > ftp://ftp.megacoder.com/pub/xmlstarlet/
> > > >
> > > > Do you have the .src.rpm available?
> > >
> > > Yup; it's there now.
> >
> > Thanks Tommy, and Ignacio too for that matter.  This is now in the FE
> > queue.  If one of you is a FE reviewer, it would be great if you could
> > take it upon yourselves to verify that all the concerns have been
> > handled.  I have no doubt Tommy's done that, and I think the .spec
> > buffed to a high "FE" gloss, so it should be a quick process.  See the
> > BZ entry:
> > https://bugzilla.redhat.com/173924
>
> Oops!  The RPM contains the *patched* sources, instead of the
> pristine sources and a patch.
>
> Give me a couple of minutes, and I'll fix it.

Can I just back out the patch on your site above?  I can do it if you're
busy, no prob.

xmlstarlet (was: Re: Advise on Fedora RPM's)

[Tommy Reynolds]

Uttered "Paul W. Frields" , spake thus:
> > > > > > ftp://ftp.megacoder.com/pub/xmlstarlet/
> > > > >
> > > > > Do you have the .src.rpm available?
> > > >
> > > > Yup; it's there now.
> >
> > Oops!  The RPM contains the *patched* sources, instead of the
> > pristine sources and a patch.
> > Give me a couple of minutes, and I'll fix it.
>
> Can I just back out the patch on your site above?  I can do it if you're
> busy, no prob.

I've posted the corrected RPM's at the address mentioned above.

This turned out to be a bit more tricky than usual.  I needed to modify
the Makefile.am file because I needed to "./autogen.sh" instead of
"configure".  Oh, well that's one.

Have lotsa fun...

xmlstarlet (was: Re: Advise on Fedora RPM's)

[Paul W. Frields]

On Tue, 2005-11-22 at 17:42 -0600, Tommy Reynolds wrote:
> Uttered "Paul W. Frields" , spake thus:
> > > > > > > 	ftp://ftp.megacoder.com/pub/xmlstarlet/
> > > > > > Do you have the .src.rpm available?
> > > > >
> > > > > Yup; it's there now.
> > >
> > > Oops!  The RPM contains the *patched* sources, instead of the
> > > pristine sources and a patch.
> > > Give me a couple of minutes, and I'll fix it.
> >
> > Can I just back out the patch on your site above?  I can do it if you're
> > busy, no prob.
>
> I've posted the corrected RPM's at the address mentioned above.
>
> This turned out to be a bit more tricky than usual.  I needed to modify
> the Makefile.am file because I needed to "./autogen.sh" instead of
> "configure".  Oh, well that's one.
>
> Have lotsa fun...

Oh I did.  BTW, where did you get that tarball?  It's not posted at the
URL referenced in your spec file.  Is it a CVS d/l?  Anyway, since they
haven't issued it as stable I slipped back to the 1.0.1 release.  I also
had to do a little sleuthing to get everything in the docs and the
program to agree to call itself "xmlstarlet".  The results are ref'd in
the Bugzilla entry:

https://bugzilla.redhat.com/173924