Please pardon my intrusion into this discussion, I'm simply an avid fan of the library and an interested user.
> Notice the deliberate use of "run both at once" and on the "same > platform", rather than "installed" and "network" This distinction is exceptionally important. > Unless you go great lengths, you will not be able to run both KDE and > Gnome for the same display, or, if you want to flash a PXE ROM, you will > have to choose between gPXE or iPXE, and won't be able to boot from both. Running two desktop environments on the same display isn't a valid comparison. Having two desktop environments _installed_ on the same machine is a much better one. There are countless large Linux installations that run Gnome and KDE at the same time, as this is a popular configuration for thin client systems. > Hudson vs Jenkins is a bit different, as one could just change the ports > to run both at once, but the expectation is that someone who wants to > setup a build review system on a server will choose one and only run > this one on that server. It would make little sense to run both, as this > would require extra work to ensure the two are in sync for little benefit. The comparison here is very thin. I don't think anybody expects their program to be able to link against both libusb and libusbx and have them play nice together. > The point is, while you may find exceptions, the main expectation is > that when people use a project that originated from a fork, they very > much select the one they think suit them best and only use that one. And > by "people" I mean end-users, developers, as well as distro maintainers. I'll agree with you that end-users and developers may prefer a fork of a given project, but many modern distributions offer both sides of a forked package, and even multiple versions of the forked packages in the case of the JRE. Additionally, _because_ developers and end-users have their own preferences (and because there are packages from thousands of developers on a single system) a distro must be able to provide, in coexistence, the preferred libraries of each user and developer on the system. > For instance, quite a few Linux distros offer either KDE or Gnome, but > not both (eg. Slackware ditched Gnome quite a few years ago), and > likewise we hope that, once someone understands the reasons for the > libusbx fork, they will see little sense in trying to have both libusb > and libusbx on the same system. Distributions that have chosen to primarily support one of KDE or Gnome do not do so out of some technical restriction, they're making a conscious choice. There's no technical conflict between both of these gargantuan pieces of software. Why? Simply because there doesn't _need_ to be. >> Please, reconsider the libusbx soname. Then provide a symlink or whatever for >> as long as libusbx API is a superset of (or equal to) libusb API. > > OK, on that subject, if it was purely up to me, because I very much want > to indicate that libusbx as a project is as disjoint from libusb as > possible, I'd have libusbx everywhere, starting with soname, header > name, directory names, as well as API prefixes. Oh, and I'm not even > sure I would bother with a compatibility layer due to the fact that the > compiler will flag any API item that needs to be changed without much of > a security risk, and such a compatibility layer would be little > different than a list of #define's (#define libusb_open libusbx_open)... Then we should begin actively discussing this issue with the people who it _is_ up to. Preferably who're going to be doing the distro packaging, because they're going to want to be a part of this. > However, the expectation is that the majority of developers we want to > cater for are current users of libusb and will very much prefer a > drop-in replacement, especially if they are not yet decided on which of > libusb or libusbx to use. Then provide a drop-in layer that provides the libusb symbols linked to the libusbx library for adventurous users who are certain that that's what they want to do. If a developer wants to use your replacement library then they'll change their Makefile/build.ninja/SConstruct file to reference it. As it stands you're going to be asking every distro maintainer that has a package that depends on libusb to choose one or the other at a time. Take a look at the apt-rdepends for libusb-1.0-0 on a modern Ubuntu machine and you'll see that you're asking for a lot. And _then_ consider that you're fairly open about not maintaining API compatibility in the future. In addition, for distributions like Debian/Ubuntu, you're now asking a bunch of package maintainers to update their packages to depend on a new virtual package that will provide something like "libusb", which will be provided by both libusb-X.X-X and libusbx-X.X-X. Why not let libusbx stand on its own merit? If a developer needs something from libusbx, surely they'll seek it out and explicitly link against it. Garret ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
