Bug#706281: t-p-u: libusb/0.1.12-20+nmu2
Control: tag -1 - moreinfo
On 2013-05-22 01:57, Cyril Brulebois wrote:
> Andreas Beckmann <anbe@debian.org> (27/04/2013):
>> I identified three packages that don't ship a SONAME symlink and cause
>> spurious creation and removal of this link by ldconfig. Spurious since
>> the packages themselves don't call ldconfig, so another installation
>> will trigger the ldconfig run - 2 seconds or 2 months later.
>>
>> As this makes the (dis-)appearance nondeterministic, this could produce
>> heisenbugs that will be hard to debug. So better ship the link in the
>> package and let dpkg instead of ldconfig manage creation/removal.
>
> I'm not sure about the practical impact, besides “it's not nice to
> have undeterministic behaviours”. AFAICT, the extra .so doesn't hurt
> when it's here (you wouldn't suggest shipping it in the package
> otherwise, right?), and nobody has ever complained about its being
> missing AFAICT from your bug report.
the src:json-c packages in unstable have a similar problem and people
are getting spurious "libjson0: error while loading shared libraries:
libjson.so.0" errors (#709512), maybe that could be attributed to this
ldconfig issue: leaving around a dangling SONAME symlink for an
indefinite time
> So I guess I'll prefer sticking to the current status quo…
>
>> libusb-dev is one of them (#706278), due to the
>> /usr/lib/<triplet>/libusb.so -> /lib/<triplet>/libusb-0.1.so.4.4.4 link.
>> The SONAME is libusb-0.1.so.4 and ldconfig will create
>> /usr/lib/<triplet>/libusb-0.1.so.4 -> libusb.so
>>
>> The attached patch adds this link to the libusb-dev package:
>> /usr/lib/<triplet>/libusb-0.1.so.4 > /lib/<triplet>/libusb-0.1.so.4
>>
>> As libusb builds an udeb, too, this will probably have to wait for r1.
>
> … especially since that was never applied in unstable anyway.
libusb 2:0.1.12-23.2 is now in unstable
Andreas
Reply to: