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 [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl