Bug#42236: [PROPOSAL] method for shlibs to work with libfoo.so
Package: debian-policy
Version: 3.0.1
Severity: wishlist
Occasionally one runs across a library libfoo.so (no soname..) I came
across two of them working on glquake and it really annoyed me that I
couldn't figure out why dpkg-shlibdeps was having a problem with it.
Leaving the argument on irc out of it, dealing with shlibs without a
soname where you have to isn't a difficult thing to do.
Turns out that the problem is ldd. If the binary is linked with the
library without a soname, the first thing that matches that will be used,
causing problems all around. =/ For some non-free packages (those
without source) this is a real PITA. And there are cases where some free
softwares use them too (alsaplayer) for internal libs. Because the Right
Thing To Do IMHO is to support these if possible/reasonable, I propose we
make an addition to the shlibs file format.
Currently the format of the shlibs file is libname soname dependency. For
those cases where it is necessary to use a library without a soname, I
suggest we use a soname of ".". Why .? Because we won't ever have a
libfoo.so.. (I hope) and it sounded good at the time.
Of course, as they say, if you want something done right, do it yourself.
If I just proposed this and we all thought it was reasonable and we made
it policy, it'd still not likely be implemented soon because nobody else
has the time. So:
--- dpkg-shlibdeps.orig Sat Jul 31 03:42:04 1999
+++ dpkg-shlibdeps Sat Jul 31 03:42:38 1999
@@ -104,6 +104,10 @@
push(@libf,$execf[$i]);
push(@libpaths,$3) if !$libpathadded{$3}++;
$nthisldd++;
+ } elsif (m,^\s+(\S+)\.so\s+=>\s+(/\S+)(\s+\(0x.+\))?$,) {
+ push(@libname,$1); push(@libsoname,"."); push(@libpath,$2);
+ push(@libf,$execf[$i]);
+ push(@libpaths,$2) if !$libpathadded{$2}++;
} else {
&warn("unknown output from ldd on \`$exec[$i]': \`$_'");
}
One caveat: The file must still be in the dpkg database. Perl is one of
those things, you either get it or you don't. I don't. => So this patch
does nothing for the problem that you have to have a shlib installed in
order to use it---even if it's part of a multi-binary package you're
building. Sorry, someone else has to fix that evilness. That's the price
of using ldd. =/
Espy has a patch that removes the need for trying to translate the output
of ldd, so maybe that can better be made to account for libs in the
debian/*/ directories..
Sorry this proposal isn't more coherent. If you can make sense out of it
and would like to try to suggest exact wording changes to the policy, be
my guest please! Otherwise I am just hoping to start the discussion and
get minds rolling in the right direction. So consider this a
meta-proposal for the moment.. =p
--
Joseph Carter <knghtbrd@debian.org> Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77 8E E2 29 96 C9 44 5F BE
--------------------------------------------------------------------------
<zpx> it's amazing how "not-broken" debian is compared to slack and rh
Reply to: