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. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f74a041.3020...@ring0.de
