Bug#358192: libusb-0.1-4: please add a symlink from libusb.so
For applications that explicitly load libusb.so at runtime with a dlopen call. In that case the application is broken. Using libusb.so instead of libusb-0.1.so.4 does not guarantee that the ABI is the right one. libusb will (probably) soon be released with a totally new ABI. Both old and new libraries will be installable at the same time, but if the application uses libusb.so, it will not know which library will be loaded. Yeah, that's a fair point. Though I would argue that keep changing the ABI isn't a great idea, and if they didn't then problems like this wouldn't arise (but I know that's an upstream issue, not the fault of your package). Richard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#358192: libusb-0.1-4: please add a symlink from libusb.so
Richard Burton a écrit : You should not need the .so file at runtime, but only during development. That's why the .so file is in the -dev package, as for other libraries, and as required by the policy. Why do you need the .so file in the library package? For applications that explicitly load libusb.so at runtime with a dlopen call. The example I came across was in an IBM driver for a Remote Supervisior Adapter card. Loading the lib at runtime isn't just to get round GPL linking issues (as I first suspected) as the driver code is also released under the GPL. (http://www-306.ibm.com/pc/support/site.wss/document.do?sitestyle=ibmlndocid=MIGR-59454) In that case the application is broken. Using libusb.so instead of libusb-0.1.so.4 does not guarantee that the ABI is the right one. libusb will (probably) soon be released with a totally new ABI. Both old and new libraries will be installable at the same time, but if the application uses libusb.so, it will not know which library will be loaded. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#358192: libusb-0.1-4: please add a symlink from libusb.so
You should not need the .so file at runtime, but only during development. That's why the .so file is in the -dev package, as for other libraries, and as required by the policy. Why do you need the .so file in the library package? For applications that explicitly load libusb.so at runtime with a dlopen call. The example I came across was in an IBM driver for a Remote Supervisior Adapter card. Loading the lib at runtime isn't just to get round GPL linking issues (as I first suspected) as the driver code is also released under the GPL. (http://www-306.ibm.com/pc/support/site.wss/document.do?sitestyle=ibmlndocid=MIGR-59454) Richard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#358192: libusb-0.1-4: please add a symlink from libusb.so
libusb package provides no libusb.so, other distros do (checked on redhat) and some software expects it. Please provide a libusb.so symlink to real lib file. Just install libusb-dev. That's a workaround, but libusb is provided by the libusb package, not the libusb-dev package. It shouldn't be necessary to install the libusb-dev package just to use the runtime library provided by a different package, and where no other components of the dev package are required. Richard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#358192: libusb-0.1-4: please add a symlink from libusb.so
Richard Burton a écrit : libusb package provides no libusb.so, other distros do (checked on redhat) and some software expects it. Please provide a libusb.so symlink to real lib file. Just install libusb-dev. That's a workaround, but libusb is provided by the libusb package, not the libusb-dev package. It shouldn't be necessary to install the libusb-dev package just to use the runtime library provided by a different package, and where no other components of the dev package are required. You should not need the .so file at runtime, but only during development. That's why the .so file is in the -dev package, as for other libraries, and as required by the policy. Why do you need the .so file in the library package? -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian GNU/Linux developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#358192: libusb-0.1-4: please add a symlink from libusb.so
Package: libusb-0.1-4 Version: 2:0.1.11-6 Severity: wishlist libusb package provides no libusb.so, other distros do (checked on redhat) and some software expects it. Please provide a libusb.so symlink to real lib file. Thanks, Richard. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages libusb-0.1-4 depends on: ii libc6 2.3.6-4GNU C Library: Shared libraries an libusb-0.1-4 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
