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. 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. As I'm now using sourceforge's subversion system to keep the files I hope this problem, once addressed, won't recur. 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? Libxml can find the system-wide catalog for DTD access, but I may need to hardcode paths to XSL files. 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. 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. There is also an empty en_US po file for new translations. So far translators have not expressed concern about the current arrangement. <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. <The upstream package is therefore not suitable for Debian at this time.> That is fine; I quite understand. <The final problem is that it requires wxwidgets2.8 when only 2.6 is currently available in Debian unstable because of various issues - one of which is the fragility of wxwidgets versions:> This is a serious problem less for my project (which I realise is a tiny niche project and intended to be such) than for wxGTK as a development platform on Debian Linux. 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+.) To be honest I'm not entirely happy even with the level of functionality offered in 2.8.x but I don't have the time to convert to Qt at this point in time. In any case I agree with you that 2.8 introduced too many incompatibilities: adjusting my code base took some time and larger projects will have had a major job on their hands. Unfortunately this also means that I can't backport my program to work with the wxGTK 2.6.x series. If you have any questions or suggestions, please let me know! Regards, Gerald -----Original Message----- From: Neil Williams [mailto:[EMAIL PROTECTED] Sent: 05 September 2007 15:09 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Gerald Schmidt Subject: A few problems OK, I've taken a quick look at this package and there are a few problems. (The "Ubuntu" package mentioned in the RFP is a .deb but it is not part of Ubuntu and there are serious errors in the packaging of that .deb) : 1. Nearly all the files in the upstream tarball are executable which is a PITA and requires a new tarball to be released with only essential scripts set to executable. (Probably only ./configure.) 2. The package includes loads of XSL that appears to have already been packaged for Debian and some of that has been modified compared to upstream. There should be an option supported by ./configure to omit these files from the 'make install' so that Debian does not have to carry duplicate XSL files. xmlcopyeditor would then depend on docbook-xsl and other similar packages that are maintained separately. If any XSL files remain after these dependencies have been identified, they can be packaged separately. This may require changes in the upstream source to use /etc/catalog.xml to locate the correct stylesheets. (See the datafreedom-qsfxsl package for an example.) http://packages.debian.org/sid/datafreedom-qsfxsl 3. There are over TWENTY licences claimed within the source! Despite that, NONE of the source files have any copyright information or any licence information: $ sudo apt-get install devscripts $ licensecheck -r . | grep -c UNKNOWN 111 $ licensecheck -r . | grep -v UNKNOWN ./ltmain.sh: GPL (v2 or later) GENERATED FILE ./src/xmlcopyeditor_private.h: GENERATED FILE I'm guessing that separating out the XSL from the C++ will mean that the C++ is under a single licence but that needs to be made explicit, preferably by specifying the typical copyright and licence header in every .cpp and .h file: /*********************************************************************** **** * filename.c * * timestamp * Copyright year name email ************************************************************************ ****/ /* This package is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see <http://www.gnu.org/licenses/ >. */ (GPL3 in this example from one of my upstream C projects.) 4. The supported translations are packaged in a non-standard way - there is no po/ directory, instead arbitrary directories are used to package the prebuilt messages.mo files. This is a very bad idea as it prevents translators within Debian from contributing to the translation effort. The package should use gettext macros and a po/ directory and package xmlcopyeditor.pot so that translations can be updated and committed back upstream. The upstream package is therefore not suitable for Debian at this time. The final problem is that it requires wxwidgets2.8 when only 2.6 is currently available in Debian unstable because of various issues - one of which is the fragility of wxwidgets versions: > We can't by any sensible measure just keep accruing wx releases in the > distro. There are apps still happily using 2.4 because an 'upgrade' > to > 2.6 will break them, though the demise of gtk1 is going to put an end > to that period of bliss eventually whether they are working or not... > > wx2.6 was rushed out prematurely, because book deadlines apparently > trump good release management, 2.8 followed fairly shortly after for > reasons which should be obvious, but not quickly enough to introduce > another transition into the etch cycle. Its the release we probably > should have had in etch, but only very few people I know of had tested > it with apps that were candidates for the distro, and though there > were some apps that already would no longer work with 2.6 in their > latest form, the needs of the many ultimately had to win the hand for etch. > > I don't know of any app that missed inclusion totally from etch for > this reason. > > So the million dollar question now, is which version do we want to > ship with Lenny. 2.8 will almost certainly be obsolete by then, and > it looks like 2.9 is going to totally break everybody's string handling yet again. > How big a nightmare that proves to be is probably also going to depend > on how many shortcuts it takes to make an intractable solution meet > another contractual deadline... http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403237 So I don't see xmlcopyeditor as a viable candidate for Debian, sorry. (I don't know if a new release could work with 2.6.) -- Neil Williams -------------- [EMAIL PROTECTED] [EMAIL PROTECTED] ================================= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
