On 2012.04.21 09:15, Vincent Pelletier wrote: > Le vendredi 20 avril 2012 12:16:49, Pete Batard a écrit : >> but hardly anyone using KDE|Gnome, gPXE|iPXE, Hudson|Jenkins is expected to >> run both at once on the same platform. > > Except KDE and Gnome can be simultaneously installed on a single system where > users can then use their favourite without locking out those who do not share > their preference. > Likewise, it's possible to use gPXE and iPXE on the same network.
Notice the deliberate use of "run both at once" and on the "same platform", rather than "installed" and "network" 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. 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 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. 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. > 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)... 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. Regards, /Pete ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
