On Wed, 5 Sep 2007 15:49:07 +0100 "G.N.Schmidt" <G.N.Schmidt@open.ac.uk> wrote: > Hi Neil > > Thanks so much for taking the time to look into the package. I have no > experience of packaging for Debian (and limited experience of packaging > for Fedora) so that I'm very grateful for your advice. > My main development platform is Ubuntu and I was hoping to create *.deb > packages rather than *.rpms soon. No problem. If you want to learn more and would like help with creating a standard .deb, try the debian-mentors mailing list: http://lists.debian.org/debian-mentors/ and the http://mentors.debian.net website too. > 1. > Yes, this is a problem that arose because I carried the files from my > Linux to my Windows partition and vice versa. When copying back from > Windows I found all settings randomised and executable permission > missing where it was required. (This also changed line endings to \r\n > which is annoying and breaks several build tools.) Under pressure of > time I applied chmod indiscriminately; hence the current permissions > mess. Release early, release often; yes. Release in haste, repent at leisure? Nah. :-) > 2. > Fair point. On Windows I had no choice in this regard, but I appreciate > that the Linux build shouldn't come with these XSL stylesheets by > default. May I ask where these stylesheets are saved on a standard Linux > system? Don't access the files directly, use /etc/catalog.xml and then refer to the stylesheets using a URI. This may look like network access but you can use --nonet to remove any possible confusion. The URI is mapped via the catalogues to a file system location so that you don't have to care where the files are actually located which removes lots of problems with your package breaking if the XSL is updated. Take a look at how my datafreedom-qsfxsl package deals with /etc/catalog.xml - you can find it via the pilot-qof source package at SourceForge and at: http://pilot-qof.cvs.sourceforge.net/pilot-qof/pilot-qof/ >Libxml can find the system-wide catalog for DTD access, but I > may need to hardcode paths to XSL files. No, you don't. :-) Even if you think you have to, you really don't. libxml2 can work with /etc/catalog.xml, just as xsltproc does - after all, xsltproc itself uses libxml2 to do that task. I've made this mistake myself and once you get your head around calling XSL as: xsltproc --nonet -o tmp/ http://www.data-freedom.org/xsl/pilot-qof-address-vcard1.xsl - it all starts to make sense. (Try it, the URI is a 404 but when the catalog is in place via the .deb package, it works.) http://pilot-qof.sourceforge.net/manual/ch02.html#vcard1 To use it via bash etc., you just need: export XML_CATALOG_FILES="/usr/share/xml/datafreedom/xsl/catalog.xml" i.e. you specify your own catalog.xml that extends the one in /etc/ and libxml2 merges the catalogues to provide a mapping to the actual XSL *and* ensures that XSL stylesheets imported by one xsl are correctly located. > 3. > Again, fair point. All original code is under GPL except where I have > adapted third-party wxWidgets components for my needs (these are under > wx license). I will add license information to the source files asap. Excellent. > 4. > I am happy to add a po directory and group the translation directories > there. That said, the directories used are not random but the ones in > which gettext locates the relevant translation files. Not random, no, just arbitrary as in you don't control the actual names of the translation locales and therefore you are likely to come across ones that are illegal directory names like st@Ltn. > There is also an > empty en_US po file for new translations. So far translators have not > expressed concern about the current arrangement. The line of least surprise is generally the best advice. > <The package should use gettext macros> It does. Getting this to work > with wxGTK is a bit tricky for plurals (you will find I had to redefine > one macro to enable string extraction for these), but I think the > mechanism is otherwise sound. OK, gettext can (and does) use plurals but you do need to use gettext directly rather than glib_gettextize or other macros (I don't know if wxwidgets has some gettext macro). The problem with gettext is that it is noisy - it forces you to press Return to confirm what it has done and therefore it can be awkward to use at the CVS/SVN stage of the upstream process. Take a look at another of my projects for how that was handled: http://gpe-expenses.cvs.sourceforge.net/gpe-expenses/gpe-expenses/ In particular, look at ./autogen.sh and the contents of po/ and po-lib/ (gpe-expenses uses multiple po directories and multiple POT files but gettext needs one po*/ directory for each, with all the .po files in the same po*/ directory as the relevant .pot file.) > wxGTK 2.6.3 is quite buggy and terribly out of date. The stable 2.8.x > series fixed many serious bugs and introduced essential functionality > such as a robust docking library and a greatly enhanced visual > components; other libraries available as wrappers in wxGTK (e.g. > Scintilla, wrapped by wxStyledTextCtrl) are updated only in 2.8.x. In > short, 2.6.3 does not offer an acceptable level of functionality for > cross-platform development. (If my project was Linux-only I'd write it > in straight GTK+.) That makes sense. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpFVo6dxqlwJ.pgp
Description: PGP signature