Bug#663916: New phonetisaurus package available
* Giulio Paci <giuliopaci@gmail.com>, 2012-10-11, 03:52:
git://git.debian.org/git/collab-maint/phonetisaurus.git.
The ugly hack in debian/rules is indeed ugly. :)
I definitively agree.
I found a cleaner way to do that and applied it (by setting
DEB_CLEAN_EXCLUDE in debian/rules).
Much better, thanks. :)
Last but not least, why do you need to recover this file? It looks
like it shouldn't have been included in the upstream tarball in the
first place.
Just because it was in the original tarball and I want that a
"debian/rules clean" results in the same content of the original
tarball.
Now I seem to recall that you told me that your workflow depends on such
restoration. Sorry for the noise.
I already contacted the author and the file will go away with next
releases (and so the ugly hack).
Great, thanks.
Oh, and Google sparse hash implemented is already packaged in Debian.
Please build-depend on libsparsehash-dev and make sure that the
system-wide copy is used, not the bundled one.
Packaging the UTF-8 library (currently in src/3rdparty/utf8/) might be
also worth considering, in order to comply with Policy §4.13.
As we are not talking about shared libraries, but about a few headers
files, I do not understand the benefits of doing so.
The main benefit is the same: you can fix bugs in one place, instead of
doing it N places (where N is usually >> 1).
I see only disadvantages:
1) using system wide files will prevent me to easily know the source
code used to compile the phonetisaurus debian package;
Convince upstream not to include them in the tarball and they will
magically stop being part of the source. </semi-kiddingly>
(Sometimes we need to keep exact source for license reasons; that's what
Built-Using field is for. This reminded me that I should review the
copyright file; see below.)
2) fixes in sparsehash will not be available to phonetisaurus unless
phonetisaurus is recompiled;
That's not worse than status quo. Also: binNMUs are cheap.
3) I will need to maintain patches to use the system-wide copy;
4) an additional dependency is introduced;
Again, convince upstream to drop the embedded copy, and these problems
will go away. :)
5) If I will package UTF-8 I will need to invest time maintaining a new
package that I do not care about and that contains just 4 headers
files.
I checked that there are at least 14 source packages in Debian that
bundle UTF8-CPP:
drizzle fife gdcm gource librime libvoikko love md5deep megaglest
mkvtoolnix paraview ruby-passenger supertuxkart vtk
Hopefully one of their maintainers would be interested in packaging it
separately. Maybe file an RFP, CCing them all?
Do you think that policy §4.13 apply in this case? I seems to me that
it is more related to shared libraries than static ones and headers.
No, §4.13 it's not only about shared library. It does apply here.
Moreover I think that the last part of the following sentence applies:
"Debian packages should not make use of these convenience copies unless
the included package is explicitly intended to be used in this way".
Do you have any evidence that this is the case (e.g. links to upstream
documentation saying this is the preferred way of using the libraries)?
FWIW, I'm personally not fond of this exception to §4.13. I think we
would be better without it. Fixing autotools bugs is definitely not fun.
Now the promised review of d/copyright:
Files: *
Copyright: 2011-2012, Josef Robert Novak
License: GPL-3+
As far as I can see, the code has been relicensed to 2-clause BSD.
Files: debian/phonetisaurus-g2p.1
No such file or directory.
Files: FstPathFinder.cpp FstPathFinder.hpp
Copyright: Chris Taylor
2011, Josef Novak
License: Apache-2.0 and GPL-3+
These now contain 2-clause BSD headers, though README.md says the "code
was licensed under the Apache license". Could you clarify this with
upstream?
Copyright/license information for src/3rdparty/google/ is missing.
--
Jakub Wilk
Reply to: