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. > > 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. > 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 > 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. I guess you missed removal of the non-free nvidia logo? -- bye, pabs http://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
