[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Advise on Fedora RPM's

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


> > 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	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 MegaCoder com" 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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]