On 06/01/2010 11:48 AM, Bill Nottingham wrote: > Elio Maldonado (emaldona@xxxxxxxxxx) said: > >> Not sure but I strongly suspect a change made to nss.spec to be the cause. >> See https://bugzilla.redhat.com/show_bug.cgi?id=596840#c7 >> > It's due to the fact that nss-softokn-freebl (actually, *all* the nss/nspr > libraires) do not fit the normal library naming, so it's not explicitly pulled for > multilib. For any update or release set that's composed with a package that explicitly > requires a compat arch of nss-softokn-freebl (such as glibc, libpurple, > pam_pkcs11, etc.), it will get pulled in via dependency resolution. F-13 > updates has none of these, so it doesn't. > > We could add some hacks to mash to get it pulled in, but I must ask... > why do all the NSS/NSPR libraries version their libraries in the library > name instead of the so version (i.e., libfreebl3.so instead of > libfreebl.so.3)? > Because upstream selected it's names before linux naming was anything like widespread. nss/nspr upstream was also unusual in considering binary compatibility breakage a sev 1 bug. It's expected that old apps run against new versions. One good side effect of this is there is no name colision in the libraries between Network Security Services and Name Switch Select, nor NSS's libssl3.so and openssl's libssl.so. bob
<<attachment: smime.p7s>>
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
