Bug#666010: ITP: nvidia-texture-tools -- image processing and texture manipulation tools
Am 28.03.2012 13:51, schrieb Paul Wise:
On Wed, 2012-03-28 at 12:25 +0200, Lennart Weller wrote:
I already got a sponsor for the package and I already completed the
packaging a few month back but thanks for offering your help.
How come you didn't file an ITP *before* packaging it? That is what ITPs
are for.
Because I did not plan to have it submitted to debian when I created it
for my ubuntu ppa.
The package is already in collab-maint [1]. And in the new queue for
unstable. It was mainly meant to allow to build 0ad. Here [2] is the
ITP for 0ad which requires nvidia-texture-tools to continue.
I see.
Here is a quick review of your packaging:
Your library versioning is broken, you should use a Debian-specific
SONAME until upstream sets that. Personally I don't think the libs
should be public, better to put them in a private dir.
In what way do you think it's broken? Also I did submit [1] the patch
for the library versioning but it got
ignored so far. Every software which would benefit from the library
currently uses the two year old
version 2.0.8 and there is more then one open request so why should the
library be hidden from the system?
02-multiarch.patch looks like it *does* need forwarding.
This way of implementing multi-arch support is debian specific so I
don't think upstream would need this. Which is also
written in the abstract of the patch. Building the library with this
patch would definitely go against the the multi-arch solution
of e.g. RHEL-based distributions.
You might want to run wrap-and-sort -sa so that diffs of the debian/ dir
are more readable.
Didn't know that tool. Thanks for mentioning it. Otherwise I would have
done this myself manually in the future.
IMO libnvtt-bin should be called nvidia-texture-tools.
I used this naming scheme because it is frequently used by other
libraries like libc-bin, ncurses-bin, libnotify-bin, libglib2.0-bin and
so on.
Of course I'm free to any suggestions on this part.
The package version has +dfsg in it but there is no indication of how
the upstream tarball was repacked and what was non-free.
I removed gnuwin32 binary files, auto-generated Visual Studio project
files (because they had no license header and were not necessary) and a
custom configure
script which broke automatic cmake building and basically called just
cmake in the first place. I will look into it to add this information to
the package.
[1] http://code.google.com/p/nvidia-texture-tools/issues/detail?id=170
Reply to: