Your message dated Wed, 4 Dec 2013 15:08:24 +0100
with message-id <20131204140824.gi4...@betterave.cristau.org>
and subject line Re: Bug#706281: t-p-u: libusb/0.1.12-20+nmu2
has caused the Debian Bug report #706281,
regarding pu: libusb/0.1.12-20+nmu2
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
706281: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706281
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian....@packages.debian.org
Usertags: unblock
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.
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.
libusb currently has a non-standard NMU version, we could fix this into
0.1.12-20.1 (or 0.1.12-20.2), but using the more canonical +deb7u1
suffix will be difficult. So I just incremented the "bad" version.
Andreas
unblock libusb/0.1.12-20+nmu2
diff -Nru libusb-0.1.12/debian/changelog libusb-0.1.12/debian/changelog
--- libusb-0.1.12/debian/changelog 2012-09-22 16:02:30.000000000 +0200
+++ libusb-0.1.12/debian/changelog 2013-04-27 18:22:54.000000000 +0200
@@ -1,3 +1,12 @@
+libusb (2:0.1.12-20+nmu2) testing; urgency=low
+
+ * Non-maintainer upload.
+ * libusb-dev: Ship /usr/lib/<triplet>/libusb-0.1.so.4 ->
+ /lib/<triplet>/libusb-0.1.so.4 symlink to prevent spurious creation of
+ that SONAME link by ldconfig. (Closes: #706278)
+
+ -- Andreas Beckmann <a...@debian.org> Sat, 27 Apr 2013 18:16:00 +0200
+
libusb (2:0.1.12-20+nmu1) testing-proposed-updates; urgency=low
* Non-maintainer upload.
diff -Nru libusb-0.1.12/debian/libusb-dev.install libusb-0.1.12/debian/libusb-dev.install
--- libusb-0.1.12/debian/libusb-dev.install 2011-07-16 12:59:12.000000000 +0200
+++ libusb-0.1.12/debian/libusb-dev.install 2013-04-27 18:15:47.000000000 +0200
@@ -1,5 +1,6 @@
usr/bin/libusb-config
usr/include/usb.h
usr/lib/*/libusb.a
+usr/lib/*/libusb-0.1.so.4
usr/lib/*/libusb.so
usr/lib/*/pkgconfig/libusb.pc
diff -Nru libusb-0.1.12/debian/rules libusb-0.1.12/debian/rules
--- libusb-0.1.12/debian/rules 2011-12-31 01:56:04.000000000 +0100
+++ libusb-0.1.12/debian/rules 2013-04-27 18:34:34.000000000 +0200
@@ -147,6 +147,8 @@
$(CURDIR)/debian/tmp/lib/$(DEB_HOST_MULTIARCH)
ln -sf /lib/$(DEB_HOST_MULTIARCH)/libusb-0.1.so.4.4.4 \
$(CURDIR)/debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libusb.so
+ ln -sf /lib/$(DEB_HOST_MULTIARCH)/libusb-0.1.so.4 \
+ $(CURDIR)/debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libusb-0.1.so.4
# Move all files in their corresponding package
dh_install -s -Nlibusb-0.1-udeb --list-missing --sourcedir=debian/tmp
--- End Message ---
--- Begin Message ---
On Mon, Sep 30, 2013 at 00:24:13 +0200, Cyril Brulebois wrote:
> Control: tag -1 moreinfo
>
> Andreas Beckmann <a...@debian.org> (2013-06-03):
> > On 2013-05-22 01:57, Cyril Brulebois wrote:
> > > 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
>
> That's not really an answer to the question about practical impacts.
>
> > > So I guess I'll prefer sticking to the current status quo…
>
> Accordingly, that's still true.
>
NAKing this one until/unless it stops being a merely theoretical issue.
Cheers,
Julien
signature.asc
Description: Digital signature
--- End Message ---