On Sun, 2005-11-20 at 14:14 -0600, Tommy Reynolds wrote: > Uttered "Paul W. Frields" <stickster@xxxxxxxxx>, 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="Tommy.Reynolds@xxxxxxxxxxxxx" 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. -- 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
