Uttered "Paul W. Frields" <stickster@xxxxxxxxx>, spake thus:
> 1. 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.
> 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.
Agree.
> 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.
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.
Attachment:
pgp3QhZwoS5ZS.pgp
Description: PGP signature
-- fedora-docs-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-docs-list
