Hi Aurelien!

2013/7/2, Aurelien Jarno <aurel...@aurel32.net>:
> On Tue, Jul 02, 2013 at 10:59:48AM +0200, Andrey Gursky wrote:
>> Hi Aurelien,
>>
>> > On Mon, Feb 04, 2013 at 08:08:08PM +0100, Andrey Gursky wrote:
>> >> Package: libusb-dev
>> >> Version: 2:0.1.12-20+nmu1
>> >> Severity: normal
>> >>
>> >> It is over a year ago since libusb has been converted to multiarch
>> >> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528205). But the
>> >> -dev package has been overseen.
>> >>
>> >
>> > For that the multiarch specification should tell what to do with config
>> > scripts in /usr/bin like /usr/bin/libusb-config, which are architecture
>> > specific.
>> >
>> > Until then such a conversion is simply not possible.
>> >
>>
>> Hmm, somehow I'm missing your answer in my mail-box. A nice suggestion
>> to solve similar problem came from Jay Berkenbilt (maintainer of icu)
>
> No it can't be used. The problem is that if you put libusb-config in a
> different package, 'libusb-config --libs' built on amd64 will still
> output '-L/usr/lib/x86_64-linux-gnu -lusb' when run on i386. This would
> be wrong.

I've noticed libusb-config is just a tiny shell script. So what would
speak against something like such patch:
if test "$echo_libs" = "yes"; then
-        echo -L@libdir@ -lusb @OSLIBS@
+        echo -L@prefix@/lib/`dpkg-architecture -qDEB_HOST_GNU_TYPE`
-lusb @OSLIBS@
fi

or even:
if test "$echo_libs" = "yes"; then
-        echo -L@libdir@ -lusb @OSLIBS@
+        echo -lusb
fi

just as the output of
pkg-config libusb --libs

Would it be enough to make the -dev package Multi-Arch: same?

>> [1]. Could that apply in case of libusb (also libusbx 1.0.x)?
>
> This is the way to go, libusb 0.1 is deprecated and programs should
> start libusb 1.0 instead.
>
> libusb 1.0.x is using pkg-config, and thus can be converted easily to
> multiarch. In fact I have already done it for the next version, I am
> just waiting for it to be released (currently at rc2).

Thanks for the recent update!

Regarding the status of libusb-0.1. There are still 87 packages
depending on libusb-0.1, compared to 81 for libusb-1.0 (in Debian
testing). Despite libusb-0.1 is considered deprecated, it is still
used. That's why I hope we could discuss some really cosmetic, not
time consuming updates to the package.

By the way, in patches there is an autoreconf one. Was it not possible
to patch only .in files and then add to rules something like:
configure: ... configure.in
        autoreconf -vfi
in order to not include this huge patch?

Regards,
Andrey


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to