Bug 15291 - upgrading from old libusb to libusb + libusb-compat fails
: upgrading from old libusb to libusb + libusb-compat fails
Status: CLOSED FIXED
Product: Codex
Classification: Unclassified
Component: libs
: stable-rc grimoire
: x86 Linux
: P3 normal
Assigned To: Grimoire Bug List
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-12 06:50 UTC by Remko van der Vossen
Modified: 2009-09-15 11:08 UTC (History)
0 users

See Also:
hgr: fixed_in_lesser_branch+
wich: integrate_to_stable_grimoire?
hgr: integrate_to_stable‑rc_grimoire?
wich: must_fix_before_release+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Remko van der Vossen 2009-07-12 06:50:03 UTC
The old version of libusb provided libusb-0.1.so.4, the new version provides libusb-1.0.so.0, with libusb-compat providing libusb-0.1.so.4. The problem here is that gnupg optionally depends on libusb, linking to libusb-0.1.so.4.

The sequence of events is:

@ libusb-0.1.so.4 exists
@ all ok
> cast libusb
- libusb and libusb-compat are queued
- libusb is cast successfully
@ libusb-0.1.so.4 has been removed, libusb-1.0.so.0 is installed
@ gpg binary now fails
- libusb-compat is cast
- hash verification of libusb-compat is initiated
- hash verification fails, since gpg fails

Obviously the cast now gives an error message that the has can not be verified and prompts whether to abort. Aborting however will lead any subsequent hash verifications to fail for any spell.

What would be a good way to resolve this?
Comment 1 Ladislav Hagara (lace) 2009-07-12 16:46:19 UTC
It was OK when I created libusb-compat. 

+2009-03-11 Ladislav Hagara <hgr@vabo.cz>
+       * DETAILS, DEPENDS: spell created, version 0.1.0
+         SOURCE_IGNORE=signature, gnupg is broken if compiled with libusb
+         verified by libusb spell as SOURCE2


I have given SOURCE_IGNORE=signature back to libusb-compat's DETAILS. When this reaches stable we can use source verification again.

fixed it test by 6619fa34f200d385ba26dc234c7f219c3fed562f
Comment 2 Remko van der Vossen 2009-07-16 09:29:34 UTC
This problem got pushed to stable with the latest stable release