Uttered "Paul W. Frields" <stickster gmail com>, 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.
Description: PGP signature