On Sun, 8 Nov 2009 19:52:17 +0100 Nicolas François <nicolas.francois(a)centraliens.net&gt; wrote: Yes, I ended up using similar things for my CVS packages. It's one reason I prefer subversion - svn-buildpackage is more "upstream-aware" than cvs-buildpackage. Not a problem, if we choose svn. svn-buildpackage works nicely with an existing upstream tarball, prepared by alternative methods like make dist. (It has to, I'm maintainer of svn-bp and I require that it obeys my upstream requirements as well as my Debian native ones.) ;-) Ah, I see. svn-bp can do that using mergeWithUpstream behaviour. I'd 'make dist' in the working copy, set that tarball as the .orig.tar.gz for svn-bp and then svn-bp merges the debian/ stuff onto the decompressed 'make dist' tarball. I'm currently playing with po4a in a local svn because it's easier to do the layout tests that I need for po4a-build. First, I'm trying to get po4a-build to work cleanly with the "assumed" layout: Script output translations: po/ Manpage output translations: doc/po HTML output translations (which could be merged with those in doc/po, as done currently with svn-bp and emdebian-rootfs): doc/www Once that's working cleanly, I'll see what is needed to get po4a-build to work with the po4a layout: Script output translations: po/bin/ Manpage output translations: po/pod/ HTML output translations : po/www The main check there is whether the Makefile snippet packaged with po4a-build is happy to accept working in po/bin instead of po/ and whether sub-directories of po/ then confuse it. This is a necessary step to ensure that po4a-build is cleared of hidden assumptions prior to a release. Is anyone on this list packaging po4a for Fedora? (I note Fedora has po4a already). It would be nice to know if the proposed po4a-build layout (for built files) is helpful or a hindrance to RPM building: script output: $(DESTDIR)/share/locale/<$lang>/LC_MESSAGES/ manpage output: doc/<$PACKAGE>/man/man1/ doc/<$PACKAGE>/man/<$lang>/man1/ html output: doc/<$PACKAGE>/html doc/<$PACKAGE>/<$lang>/html I might investigate whether po4a-build should be sensitive to DESTDIR too. po4a-build does it this way because that's useful for Debian packaging (so that our .install files can just use doc/$<PACKAGE>/* to include both translated and untranslated content without needing updates each time a new translation is added *and* allowing manpages for one script to be packaged separately to manpages for a different script. ($PACKAGE in the above corresponds to the *binary* package name in Debian, whereby one source package builds multiple binary packages and the manpage needs to accompany the script it describes but *may* be translated from a set of PO files that cover *multiple* scripts.) So, if source package foo builds bar and baz, we could have: <$prefix>./usr/share/locale/fr/LC_MESSAGES/bar.mo <$prefix>./usr/share/locale/fr/LC_MESSAGES/baz.mo ./doc/bar/man/man1/bar.1 ./doc/bar/man/fr/man1/bar.1 ./doc/baz/man/man1/baz.1 ./doc/baz/man/fr/man1/baz.1 bar then needs only: ./usr/share/locale/*/LC_MESSAGES/bar.mo ./doc/bar/* It's years since I built RPM's, I can't remember whether this path simplification would be useful or not. It certainly helps in Debian. (The script output behaviour mimics exactly what happens with normal autotools usage in intltool, line of least surprise etc.) -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/