[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#663916: New phonetisaurus package available

* Giulio Paci <giuliopaci@gmail.com>, 2012-10-11, 03:52:
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: