Bug#221982: glibc's at fault here...
On Wed, May 05, 2004 at 12:07:08AM -0400, Daniel Jacobowitz wrote:
> On Tue, May 04, 2004 at 06:25:20PM +0200, Jeroen van Wolffelaar wrote:
> > retitle 221982 Please put nss modules in /lib/nss/ (or something like that)
> > severity 221982 wishlist
> > reassign 221982 glibc
> > thanks
> >
> > Please keep myself in the Cc list.
> >
> > On Wed, Apr 21, 2004 at 02:03:33PM -0700, Jeff Bailey wrote:
> > > On Wed, Apr 21, 2004 at 10:10:43PM +0200, Jeroen van Wolffelaar wrote:
> > >
> > > > glibc is misplacing libnss_* according to Andrew Suffield.
> > >
> > > > Disclaimer: I don't know that these files do, I trust this to the
> > > > descretion of the glibc maintainers :).
> > >
> > > It's all good. Andrew's wrong in this particular case. Those files are
> > > used to help glibc figure out things like how to read /etc/passwd and
> > > such. These all are useful when /usr hasn't been mounted yet (and could
> > > potentially be required for mounting it off of a remote NFS volume)
> >
> > Shouldn't it be in /lib/nss/ then? This is a good reason to not put it
> > in /usr/lib/<package>/, but, I don't see why it shouldn't be in
> > /lib/(nss|glibc-modules|whatever)/. These files are indeed no shared
> > libraries, which makes it unnessasary (and against FHS if you're reading
> > it in a certain way) to put them directly in /lib.
>
> You can link to them directly as shared libraries if you want to. They
> are valid shared libraries. I don't see how the fact that normal use
> uses dlopen makes them any less shared libraries.
I was busy yesterday with shared libraries & lintian, and the
discriminating factor according to lintian turns out to be:
has a SONAME or not. According to policy, shared libraries do need a
SONAME. I also look a bit closer to how glibc handles it, and indeed I
agree with you it are shared libraries (that no other package uses them
directly doesn't matter). But:
Suppose the first digit indicates indicate the amount of backwards
compatibility, and if either of the two others change, binary backwards
compatibility is maintaind (it looks like that way).
Then, this should be the layout:
libc6:
- libnss_dns.so.2 -> libnss_dns.so.2.3.2 (symlink)
- libnss_dns.so.2.3.2 (actual library, with soname 'libnss_dns.so.2'
libc6-dev:
- libnss_dns.so -> libnss_dns.so.2 (symlink)
- libnss_dns.a (static library for the sake of programs using this
library)
The problem with libc is that the filename is a bit weird (version
before the .so) but that's not really a problem, but that there are
symlinks etc, but no soname.
If these are shared libraries, which they very much seem to be, then the
soname should be set to libnss_dns.so.2 (in this case), and a shlibs
entry for programs who wish to use that same library too. For the
latter, you'll also need to add the static library in the -dev package
(the .a file).
It is actually a policy violation as it is now, but since it'd be very
unfortunate if changes to these files turn out to have unforseen
implications (I doubt it, but you can better play safe) this close to
the Sarge release, I won't inflate the severity now. Adding a soname is
quite zero-risk though: add '-Wl,-soname,libnss_dns.so.2' to the gcc
line compiling libnss_dns-2.3.2.so (etc). Also extra shlibs entries
don't hurt. And the strange filename is both quite unimportant, not
clear it's wrong at all (just not like it is done usually), and of
course way too risky to change right now.
I'll make sure the lintian errors are much more clear by the way, if you
run lintian with -i you'd have seen explaination, but the tag is a bit
misleading.
> I'd rather add shlibs entries for them, or a lintian exception. They
> do not violate policy by living in /lib.
Agree about the /lib: after looking closer they indeed are simple shared
libraries. I was a bit 'distracted'[1] by the initial bugreport --
sorry. And by the unclear lintian error :).
Kind regards,
--Jeroen
[1] This isn't exactly the word I was looking for, but as a non-native
English speaker, it comes closest to what I could think of.
--
Jeroen van Wolffelaar
Jeroen@wolffelaar.nl (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
Reply to: