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

Bug#663916: New phonetisaurus package available



Il 10/10/2012 22:59, Jakub Wilk ha scritto:
> * Giulio Paci <giuliopaci@gmail.com>, 2012-10-09, 02:16:
>> 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).

> 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.
I already contacted the author and the file will go away with next releases (and so the ugly hack).

> 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.
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;
2) fixes in sparsehash will not be available to phonetisaurus unless phonetisaurus is recompiled;
3) I will need to maintain patches to use the system-wide copy;
4) an additional dependency is introduced;
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.

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.
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".

Bests,
	Giulio.


Reply to: