Hi!
Thank you for your review.
Il 13/10/2012 00:02, Jakub Wilk ha scritto:
> * Giulio Paci <giuliop...@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.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
