On Sun, 2005-11-20 at 11:53 -0600, Tommy Reynolds wrote: > Uttered "Paul W. Frields" <stickster@xxxxxxxxx>, 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? > > 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 ;-) 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. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-docs-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-docs-list
