Bug#435888: A few problems
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:codehelp@debian.org]
Sent: 05 September 2007 15:09
To: 435888@bugs.debian.org
Cc: 435888-submitter@bugs.debian.org; 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
--------------
codehelp@debian.org
codehelpgpg@users.sourceforge.net
=================================
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
Reply to: