Bug#663916: New phonetisaurus package available
Hi!
There has been a new phonetisaurus release (0.6).
All the patches have been applied upstream, the backup file in sparsehash has been removed, FstPathFinder.* have been rewritten from scratch.
I updated the Debian package files accordingly. All the phonetisaurus files have a BSD-2-clause header, but the README.txt reports BSD-3-clause. I will ask upstream about this.
Bests,
Giulio.
Il 13/10/2012 15:54, Giulio Paci ha scritto:
> Hi!
> Thank you for your review.
>
> Il 13/10/2012 00:02, Jakub Wilk ha scritto:
>> * Giulio Paci <giuliopaci@gmail.com>, 2012-10-11, 03:52:
>>>>> git://git.debian.org/git/collab-maint/phonetisaurus.git.
>
>>>> 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.
>
> No problem.
>
>>>> 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).
>
> Yes, I understand the goal, but I am worried that using external source code would make it harder to replicate possible issues (I will need the exact version of the
> libsparsehash-dev binary package that was used to compile the library).
> However this is probably true for many other C++ libraries. It is just more evident here, where the libraries are just simple header files.
>
>>> 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;
>> (Sometimes we need to keep exact source for license reasons; that's what Built-Using field is for.)
>
> How can I set Built-Using field? Should I set it by hand? Is it possible to set it automatically?
>
>>> 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.
>
> Maybe I am missing something in the upload process (well, I am missing almost everything to be honest).
> Can you point some reference that will help me understanding what will happen when new releases of libsparsehash-dev will be released (and phonetisaurus will need
> recompilation)?
>
>>> 3) I will need to maintain patches to use the system-wide copy;
>
> Created, applied and forwarded a patch for this.
>
>>> 4) an additional dependency is introduced;
>>
>> Again, convince upstream to drop the embedded copy, and these problems will go away. :)
>
> Additional dependency introduced. :-) If the patch will be accepted upstream, the patch will let upstream to compile embedded copy of the libraries and us to compile using
> the system-wide dependency.
>
>>> 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?
>
> If you think it is useful, I will do this. However I would like to understand how I am supposed to deal with this kind of libraries before doing this.
> With the patch above, it will be very easy to use the system-wide utfcpp library once it is packaged.
>
>>> 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.
>
> Ok, using libsparsehash-dev then.
>
>>> 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)?
>
> No, I have no evidence about it, but the documentation is scarce in this sense. Both libraries report something like:
> "You just need to put the .h files somewhere your compiler can see this."
> I just thought that sparsehash and utf8 are similar enough to gnulib that people would use them in the same way.
>
>> 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.
>
> I see your point of view.
> But not being able to understand if autotools files are not working on others' systems because of different version of tools or because problems in the environment is also
> 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.
>
> Right, fixed.
>
>>> Files: debian/phonetisaurus-g2p.1
>>
>> No such file or directory.
>
> Also fixed.
>
>>> 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?
>
> This code is partially covered by Apache 2.0 license and partially by the BSD-2-clause license.
> Upstream tried to contact Chris Taylor in the past, but he was not able to talk to him.
> He is thinking about rewriting these files from scratch.
>
>> Copyright/license information for src/3rdparty/google/ is missing.
>
> Added.
>
> Bests,
> Giulio.
Reply to: