Bug#666010: ITP: nvidia-texture-tools -- image processing and texture manipulation tools
Am 29.03.2012 02:17, schrieb Paul Wise:
> On Wed, 2012-03-28 at 22:40 +0200, Lennart Weller wrote:
>
>> Because I did not plan to have it submitted to debian when I
>> created it for my ubuntu ppa.
>
> Hmm, OK.
>
>> 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?
>
> Firstly, source code version and SONAME are completely different
> things. There is no reason to start the SONAME at 2, it should
> start at 0. Secondly, if upstream is not producing properly
> versioned shared libraries, it is very inappropriate to trample
> their SONAME name-space and much better to use a Debian-specific
> SONAME. If upstream chooses 0 as the SONAME and then makes two new
> releases with an incompatible ABI, they will be up to SONAME 2
> which will be ABI incompatible with the Debian SONAME 2.
The SONAME starting with 2 was suggested by my supporter and I
understand the reasoning for it. The upstream developer seems to only
break ABI in major versions and if someone creates a package for
version 1.* than there won't be any conflicts. Also the upstream
package does not contain any SO versioning for the current stable
release. But I will contact the upstream developer about these concerns.
>>> 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.
>
> I don't know CMake that well but it appears that upstream is
> incorrectly hard-coding the lib install directory. Anyone wanting
> to customise the library dir will get the wrong result. RHEL/Fedora
> distributions don't support proper multi-arch, they only have
> bi-arch (aka multilib). When they start switching to proper
> multi-arch, they are going to need that patch so it is best to get
> it upstream now.
In the upstream version you can currently choose the PREFIX of the
installation but it will always be installed to PREFIX/lib. That was
fixed by my patch. But as I said I will talk with the upstream author
and try to have it added to his version.
>> 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.
>
> Well, ultimately the library isn't the most important part of the
> package, the important bit is the command-line tools and they
> should be named appropriately. The libraries come from an embedded
> code copy of nvidia-oss, not from nvidia-texture-tools itself. I
> would say the name of the package with the binaries should reflect
> the above.
>
> Embedded code copies are discouraged in Debian. There are also the
> libsquish and poshlib embedded code copies. Please inform the
> security team about these issues if the package reaches the
> archive.
>
> http://wiki.debian.org/EmbeddedCodeCopies
> http://code.google.com/p/nvidia-oss/
> http://code.google.com/p/libsquish/ http://hookatooka.com/poshlib/
>
> In addition, libsquish can be built with SSE or Altivec on the
> appropriate platforms, increasing its speed. By embedding
> libsquish, nvidia-texture-tools is missing out on that speed-up.
> Since
As you can see in the nvidia-oss repository there was no changeset
since 2009 where
as nvidia-texture-tools received changes to former nvidia-oss
directories upto the stable
release in 2010 and is still being updated for the next release. Thats
why I didn't use the nvidia-oss version. With the other libraries you
have a fair point and I will package them seperatly for the next
upstream release.
>> 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.
>
> You should have a get-orig-source debian/rules target to
> automatically build/repack the tarball. Please see debian-policy
> for info on that.
Okay I will look into that and add the target.
> I guess you missed removal of the non-free nvidia logo?
Those icons were also inside the visual studio project directories. I
didn't even notice that I erased them as the whole directory structure
wasn't important to the package.
Reply to: