Le 2012-05-25 09:25, Tom Gundersen a écrit :
> On Fri, May 25, 2012 at 3:18 PM, Thomas Bächler  wrote:
>> Am 25.05.2012 14:56, schrieb Tobias Powalowski:
>>> Hi got this feature request:
>>> https://bugs.archlinux.org/task/29999
>>>
>>> - fedora ditched the libusb usage in favour of the libusbx project.
>>>
>>> http://www.libusbx.org
>>>
>>> Shall we move to this too?
>> Questions not answered in the bug report:
>> 1) What is an actual issue solved by libusbx that is present in libusb?
>> (by Allan)
>> 2) Is it a drop-in replacement that is API-compatible or (better)
>> ABI-compatible.
>>
>> ad 1) I guess there are such issues, otherwise the libusbx people
>> wouldn't have been angry enough to make a fork. This point requires
>> research.
> From what I gathered, the difference is currently minimal as the
> libusb maintainer backported most of the commits from libusbx. I
> assume this can not go on forever though...
>
>> ad 2) If it is ABI-compatible, there is no harm in switching right now,
>> as libusbx = libusb-1 + active development + more bugfixes. If it is
>> only API-compatible or partially incompatible, we would need a strong
>> reason to actually switch.
> It was advertised as a drop in replacement, I assumed this means ABI
> compatible, but this we must check.
>
> -t

I was curious, so I tried the pkg from AUR [1]. My usb stuff still work,
so I guess compatibility is not a issue. The choice will probably be
done by considering which of the two projects is the most promising.

Stéphane

[1] https://aur.archlinux.org/packages.php?ID=59473

On Fri, May 25, 2012 at 2:56 PM, Tobias Powalowski wrote:

...

Hi got this feature request: https://bugs.archlinux.org/task/29999

- fedora ditched the libusb usage in favour of the libusbx project. Seems Debian have done/will do the same.

...

http://www.libusbx.org

Shall we move to this too? I am not very familiar with the background story, but from what I can gather from libusb-devel[0], it seems that the fork was done for a good reason, has lots of support, and no counterarguments have (as far as I could find at least) been presented by the libusb maintainer.

To sum up, the main complaints were: libusb was not begin released for more than two years (it has now finally been released, after the fork happened), and the maintainer was seen as hostile to new contributions.

Assuming the impression I got is correct, I would be in favor of switching.

Cheers,

Tom

[0]: http://libusb.6.n5.nabble.com/libusb-is-dead-long-live-libusbx-td5651413.htm... replaces=('libusb1' 'libusb')

Am 25.05.2012 15:21, schrieb Tom Gundersen: provides=('libusb') would that be ok in PKGBUILD? -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org

On Sun, May 27, 2012 at 9:44 AM, Tobias Powalowski wrote:

Am 25.05.2012 16:14, schrieb Tobias Powalowski:

...

...

On Fri, May 25, 2012 at 2:56 PM, Tobias Powalowski wrote:

...

Hi got this feature request: https://bugs.archlinux.org/task/29999

- fedora ditched the libusb usage in favour of the libusbx project. Seems Debian have done/will do the same.

...

http://www.libusbx.org

Shall we move to this too? I am not very familiar with the background story, but from what I can gather from libusb-devel[0], it seems that the fork was done for a good reason, has lots of support, and no counterarguments have (as far as I could find at least) been presented by the libusb maintainer.

To sum up, the main complaints were: libusb was not begin released for more than two years (it has now finally been released, after the fork happened), and the maintainer was seen as hostile to new contributions.

Assuming the impression I got is correct, I would be in favor of switching.

Cheers,

Tom

[0]: http://libusb.6.n5.nabble.com/libusb-is-dead-long-live-libusbx-td5651413.htm... replaces=('libusb1' 'libusb')

Am 25.05.2012 15:21, schrieb Tom Gundersen: provides=('libusb') would that be ok in PKGBUILD?

Would it be ok for you if i bring this to testing repository?

+1 -t

On 01/06/12 17:19, Tobias Powalowski wrote:

...

On Sun, May 27, 2012 at 9:44 AM, Tobias Powalowski wrote:

...

Am 25.05.2012 16:14, schrieb Tobias Powalowski:

...

...

On Fri, May 25, 2012 at 2:56 PM, Tobias Powalowski wrote:

...

Hi got this feature request: https://bugs.archlinux.org/task/29999

- fedora ditched the libusb usage in favour of the libusbx project. Seems Debian have done/will do the same.

...

http://www.libusbx.org

Shall we move to this too? I am not very familiar with the background story, but from what I can gather from libusb-devel[0], it seems that the fork was done for a good reason, has lots of support, and no counterarguments have (as far as I could find at least) been presented by the libusb maintainer.

To sum up, the main complaints were: libusb was not begin released for more than two years (it has now finally been released, after the fork happened), and the maintainer was seen as hostile to new contributions.

Assuming the impression I got is correct, I would be in favor of switching.

Cheers,

Tom

[0]: http://libusb.6.n5.nabble.com/libusb-is-dead-long-live-libusbx-td5651413.htm... replaces=('libusb1' 'libusb')

Am 25.05.2012 15:21, schrieb Tom Gundersen: provides=('libusb') would that be ok in PKGBUILD?

Would it be ok for you if i bring this to testing repository? +1

-t

Am 27.05.2012 12:13, schrieb Tom Gundersen: libusbx is now in testing.

greetings tpowa

Should be provides=("libusb=$pkgver")

Am 01.06.2012 11:04, schrieb Andrea Scarpino:

On 1 June 2012 10:20, Allan McRae wrote:

...

Should be

provides=("libusb=$pkgver") Also, conflicts=("libusb") is missing.

error: failed to commit transaction (conflicting files) libusbx: /usr/include/libusb-1.0/libusb.h exists in filesystem libusbx: /usr/lib/libusb-1.0.a exists in filesystem libusbx: /usr/lib/libusb-1.0.so exists in filesystem libusbx: /usr/lib/libusb-1.0.so.0 exists in filesystem libusbx: /usr/lib/libusb-1.0.so.0.1.0 exists in filesystem libusbx: /usr/lib/pkgconfig/libusb-1.0.pc exists in filesystem

fixed. -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org