please create libusb-legacy

[michaelld (Michael Dickens)]

With ticket:20387, the port 'libusb' is now the new version 1.0 series instead of the legacy 0.1 series. Although the legacy version is 3+ years old, some projects (e.g., GNU Radio) still use it and aren't easily upgraded to the 1.0 series or even the 1.0-compat version. Could someone please create a new port, maybe "libusb-legacy", that revives 0.1.12 as it was before (i.e., as of r53249)? Thanks!

[tobypeterson]

libusb-compat should be 100% API-compatible (although perhaps not ABI-compatible, but we did bump the revisions).

I'd prefer that we work with the libusb maintainers to resolve any compatibility issues, because it *should* be compatible. Can you please provide more information about the specific failure? At the very least, the usual info (debug log, relevant versions).

[tobypeterson]

Also:

Not sure what r53249 has to do with this, considering that it was just a minor build fix. We don't seem to have a port for GNU Radio, so I'm not sure how this is even relevant.

[michaelld (Michael Dickens)]

Re: Comment1:

FBoFW, GNU Radio needs access to parts of the non-static internal API and hence is dependent on version 0.1.10+ . Version 1.0-compat breaks the internal API in many ways, both in variables and structs. Yes, the external API looks to be very compatible between 0.1.12 and 1.0-compat, but for projects that require the internal API: only the legacy version will do.

Yes, GNU Radio (and similar projects) should upgrade to the 1.0 series or at very minimum not use the internal API so-as to be able to use 1.0-compat. It takes time to upgrade projects (yes, GNU Radio folks are discussing what to do right now), and for many cross-OS projects -- because most Linux distros still provide version 0.1.12, not the new 1.0 version or 1.0-compat -- fixing just the OSX/darwin port is not a high priority (as is the case for GNU Radio). Hence, at least for the mean time, providing a legacy Port of libusb would allow such projects more time to figure out what to do -- knowing that -something- has to be done sooner rather than later.

[michaelld (Michael Dickens)]

Re: Comment2:

r53249 is the last revision of the libusb Portfile (and files) that provides the legacy version (0.1.12, with fixes for OSX 10.6). What I'd like to see is this revision moved to a port named "libusb-legacy".

I've submitted Portfiles for GNU Radio version 3.2; see ticket:18104 . These Portfiles will not work with the new libusb -- they require the legacy (0.1.10+) version, so I need to re-work the Portfiles before they become active. I have no idea what the status is of them being accepted or not.

[tobypeterson]

It's not as simple as restoring the old Portfile - it will conflict with the libusb-compat port. Probably need to make a "libusb-gnuradio" port that installs different libs, and modify gnu radio to use it.

[michaelld (Michael Dickens)]

I understand that you do not want to revert the 'libusb' port back to r53249; I'm not requesting that. What I'm requesting is that I / you / someone create a --new-- port called "libusb-legacy" (or something like that) based upon the files from libusb as of r53249 -- changed appropriately so that not both libusb-compat and libusb-legacy can be installed at the same time (since many, if not all, of their installed filenames are identical and would conflict). Yes, one could create a new port called "gnuradio-libusb" (or something like that), but 'libusb-legacy' is a better description.

[nerdling (Jeremy Lavergne)]

Since it seems we keep missing that this is a request for a new port, updating some data to better indicate this.

[nerdling (Jeremy Lavergne)]

Created in r54871.

[nerdling (Jeremy Lavergne)]

Make that r54873.

[michaelld (Michael Dickens)]

Thank you for the quick turn-around. I'll update the GNU Radio Portfiles for the latest release (3.2.2) and to use libusb-legacy, and upload them -- soon but probably later today.

[tobypeterson]

Reopening. libusb-legacy conflicts with libusb-compat.

[nerdling (Jeremy Lavergne)]

Conflicted items are:

• /opt/local/bin/libusb-config
• /opt/local/include/usb.h
• /opt/local/lib/libusb-0.1.4.dylib
• /opt/local/lib/libusb.a
• /opt/local/lib/libusb.dylib
• /opt/local/lib/libusb.la
• /opt/local/lib/pkgconfig/libusb.pc

[tobypeterson]

r55081

[michaelld (Michael Dickens)]

Thank you for being attentive to this request. That said, I liked the original version better, when file names weren't changed; I can no longer use this port -directly- with GNU Radio, instead finding some indirect means to get GR's configure script to detect the presence of libusb-legacy (without changing the configure script to look for libusb-legacy.pc). I understand that there was a conflict between the compat and legacy (as I mentioned earlier), and hence a need to do -something- quickly.

My preference is keep complete filename and functionality backwards compatibility of both LIBUSB legacy and compat (NOT at the same time), and insert a check in the Portfile of each to make sure the other isn't installed (and error out if so with a brief message about picking one or the other). Those ports which rely upon one or the other could then look for the file $prefix/lib/pkgconfig/libusb.pc and be happy if installed (by either port) -- and it would be the user's choice as to which to install and use: the faster but just external-API compatible compat, or the slower but guaranteed to be functional internal and external legacy.

This latter seems like a more robust and functional solution: one which does not require changes to any projects making use of the older libusb.