A new ebuild for the libusb-0.9.3_beta Reproducible: Always Steps to Reproduce: 1. compiles fine
Created attachment 172449 [details] Ebuild for libusb-0.9.3_beta
Created attachment 175266 [details] Ebuild for libusb-1.0.0
compiles and installs fine.
Maybe it is time to start discussion on migration to libusb-1.0.0 with the compat layer for 0.1?
*** Bug 256933 has been marked as a duplicate of this bug. ***
Created attachment 181401 [details] libusb-1.0.0.ebuild Ebuild including compat dependencies
Created attachment 181404 [details] libusb-0.1.99.ebuild Meta ebuild providing SLOT 0 (since we cannot provide two slots).
Created attachment 181406 [details] dev-libs/libusb-compat/libusb-compat-0.1.0.ebuild The actual compat ebuild
Created attachment 183746 [details] dev-libs/libusb-1.0.0.ebuild why so complicated? Adding libusb-1.0.0 with a +compat USE flag and a PDEPEND on dev-libs/libusb-compat seems to work perfectly here (tested with hal and usbutils so far).
Created attachment 183747 [details] dev-libs/libusb-compat-0.1.0.ebuild
(In reply to comment #9) > Created an attachment (id=183746) [edit] > dev-libs/libusb-1.0.0.ebuild > > why so complicated? My intention was to allow ebuilds to depend on SLOT=0 meaning they either need the original libusb or newer libusb with compat support. Using only the useflag the DEPEND string will be more complicated.
So you'd just use DEPEND="dev-libs/libusb:0" if either libusb-0 or libusb-compat is needed and DEPEND="dev-libs/libusb:1" otherwise? The problem is that according to upstream even though libusb-compat is mostly compatible to libusb-0 there may be apps which don't work with libusb-compat due to changed behaviour when interrupting transfers. So we probably need some testing anyway. In case an app works we'd use "|| ( <=dev-libs/libusb-0* dev-libs/libusb-compat )" or ">=dev-libs/libusb-1" otherwise. Here's a list of revdeps for libusb: app-accessibility/brltty app-accessibility/gok app-crypt/asedriveiiie-serial app-crypt/asedriveiiie-usb app-crypt/asekey app-crypt/ccid app-crypt/gnupg app-misc/acdctl app-misc/digitemp app-misc/g15daemon app-misc/ifp-line app-misc/lcd4linux app-misc/lcdproc app-misc/lirc app-misc/logitech-applet app-misc/razertool app-misc/rioutil app-mobilephone/bitpim app-mobilephone/gnokii app-mobilephone/moto4lin app-mobilephone/obex-data-server app-mobilephone/openmoko-dfu-util app-pda/barry app-pda/coldsync app-pda/pilot-link app-text/calibre dev-embedded/avrdude dev-embedded/ftdi_eeprom dev-embedded/libftdi dev-embedded/openocd dev-embedded/pk2cmd dev-libs/cyberjack dev-libs/libg15 dev-libs/libhid dev-libs/luise-bin dev-libs/openct dev-libs/openobex dev-libs/serdisplib dev-util/usb-robot kde-base/kcontrol kde-base/kdebase kde-base/systemsettings media-gfx/gphoto2 media-gfx/iscan media-gfx/sane-backends media-libs/hamlib media-libs/libdjconsole media-libs/libgphoto2 media-libs/libifp media-libs/libkarma media-libs/libmtp media-libs/libnjb media-libs/libptp2 media-sound/ardour media-tv/linuxtv-dvb-apps media-video/isight-firmware-tools net-dialup/umtsmon net-misc/zaptel net-print/hplip net-print/mtink net-wireless/bluez net-wireless/bluez-utils net-wireless/wispy-tools sci-geosciences/gpsbabel sci-geosciences/qlandkarte sci-libs/indilib sci-libs/libticables2 sys-apps/hal sys-apps/ifd-gempc sys-apps/lomoco sys-apps/pcsc-lite sys-apps/usb_modeswitch sys-apps/usbutils sys-auth/thinkfinger sys-fs/owfs sys-libs/libchipcard sys-power/nut sys-power/sispmctl x11-misc/ifpgui xfce-extra/xfce4-cellmodem
(In reply to comment #12) > So you'd just use DEPEND="dev-libs/libusb:0" if either libusb-0 or > libusb-compat is needed and DEPEND="dev-libs/libusb:1" otherwise? Maybe I am missing something, but how would libusb-1[compat] fulfill the :0 requirement? As far as I remember, changing SLOT based on a use flag is not allowed, and providing two SLOTs does not work as well. That is why I attached two libusb ebuilds (one to provide SLOT 0 and depend on libusb-compat and one that is SLOT 1 and provides the actual code). As far as the rest of your plan goes, that is a good idea!
Is this bug going to be solved any time soon? If not, I will bump gammu w/o libusb-1.0 support.
mrness: I haven't seen any further discussion between rbu and dev-zero as to which approach would actually work.
dev-zero and I discussed this back in March and never documented the outcome of it. I hope I am not misquoting Tiziano, but we came up with this solution: * keep libusb:0 ebuilds as they are * bump libusb-1.0.0 in the tree with the :1 SLOT * add libusb-compat-0.1.0 ebuild to the tree that depends on libusb:1 Then, add * virtual/libusb:0 with DEPEND="|| ( dev-libs/libusb:0 dev-libs/libusb-compat )" * virtual/libusb:1 with DEPEND="dev-libs/libusb:1" and change DEPEND strings of all ebuilds that are in the tree. We also discussed a virtual/libusb-compat but that seems to be a less clean solution than a properly slotted virtual.
All done: virtual/libusb-{0,1} dev-libs/libusb-compat dev-libs/libusb-1* Remaining: Fixing up all existing libusb dependancies to libusb:0 for now, and then testing every single one manually.
rbu/dev-zero: one thing I saw in the previous attachments here, but not in the latest one, is that libusb-compat-0* blocked libusb-0*. I didn't include it since it wasn't in your latest ebuilds, but I'm wondering if we do need it. See also my mail to -dev about migration.
Hi, Just sync my portage, and dev-libs/libusb-1.0.1 was there...but now sys-apps/usbutils-0.82 won't compile anymore: checking for LIBUSB... configure: error: Package requirements (libusb >= 0.1.12) were not met: No package 'libusb' found Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables LIBUSB_CFLAGS and LIBUSB_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. Should I talk about this here, or create a separated bug report for usbutils?
florian: usbutils is fixed already. To clarify from my email: 1. By testing, I mean that the applications needs to be run. 2. Recompiling is NOT needed when switching from libusb-0* to libusb-compat.
Robbat, yes that blocker is needed: Since libusb-compat installs the same stuff as libusb:0 does, libusb:0 needs a blocker on libusb-compat and vice-versa.
dev-zero: libusb-compat/libusb:0 block each other now.
> usbutils is fixed already. Sorry to say this: No, its not. The changed usbutils ebuilds depend on virtual/libusb:0, but both virtual/libusb-0 and virtual/libusb-1 are SLOT 0, so the need for libusb-compat is not visible for portage. Trying to revdep-rebuild the system after the removal of libusb-0.1.12-r5 the emerge of sys-apps/usbutils-0.82 and media-libs/libgphoto2-2.4.4 failed. After manually installing libusb-compat the emerge of libgphoto2 worked, so just changing the dependencies of that ebuild should work.
(In reply to comment #23) Fixed.
I've opened bug 270039 as a tracker for the package changes needed in the tree (and I fixed a number of the popular packages already). Closing this bug now, since it this is actually in the tree.
