Is it possible to dynamize "requires" at RPM build time?

[Nicholas Miell]

On Wed, 2006-08-23 at 15:08 -0700, Nicholas Miell wrote:
> On Wed, 2006-08-23 at 23:34 +0200, Kai Engert wrote:
> > Tomas Mraz wrote:
> > > On Wed, 2006-08-23 at 16:31 -0400, Jesse Keating wrote:
> > >   
> > >> On Wednesday 23 August 2006 16:18, Hans de Goede wrote:
> > >>     
> > >>> Actually afaik gnome and gtk have the exact same problem (they are fully
> > >>> backward compatible but introduce new symbols making apps using these
> > >>> new symbols break on older version), but there we've been plastering
> > >>> over the problem by manually adding Requires to packages.
> > >>>       
> > >> I just talked to some of our Gnome maintainers and they don't think that's the 
> > >> case at all.
> > >>
> > >> Isn't that why you have foo-so.1 and foo-so.1.1?  Your build that has 
> > >> foo-so.1.1 could include foo-so.1 for compat no?  Am I totally off base here?  
> > >> Versioned libraries are here for a reason, so that you can know what soname 
> > >> you're compiling against and need later on down the road.  Having random 
> > >> symbols in random unversioned .so files seems very very wrong to me, as a 
> > >> shared library.
> > >>     
> > >
> > > No, they would have to use versioned symbols for this purpose.
> > >
> > > See http://people.redhat.com/drepper/dsohowto.pdf section 3.
> > >   
> > 
> > Exported symbol in NSS shared libraries are tagged with the number of 
> > the first version that contained the symbol. I used this command to grep 
> > for the new symbols in the most recent FC5 update:
> > 
> > [root at kaiez1 tmp]# readelf -a /usr/lib/libnss3.so |grep -i 3\.11\.1
> >    230: 4f2ed4a0   320 FUNC    GLOBAL DEFAULT   11 
> > NSS_RegisterShutdown@@NSS_3.11.1
> >    553: 4f2ed400   151 FUNC    GLOBAL DEFAULT   11 
> > NSS_UnregisterShutdown@@NSS_3.11.1
> >    666: 4f3302e0    22 FUNC    GLOBAL DEFAULT   11 
> > SEC_ASN1EncodeUnsignedInt@@NSS_3.11.1
> >    749: 4f2f0fc0    86 FUNC    GLOBAL DEFAULT   11 
> > SEC_RegisterDefaultHttpCl@@NSS_3.11.1
> > (excerpt)
> > 
> > Kai
> 
> So the question becomes, why isn't the Firefox RPM requiring those
> symbol versions?
> 
> nss3 provides them ("libnss3.so(NSS_3.3)", "libnss3.so(NSS_3.9.3)",
> etc.), but the only thing that Firefox requires is "libnss3.so" and a
> manually specified "nss >= 3.10".
> 
> Of course, I'm not sure this would actually help in the static archive
> case that actually caused the problem here, but RPM should be picking up
> the necessary symbol versions. libpipnss.so certainly requires them.

And the answer appears to be:

Firefox is using it's own custom dependency generator script, which
calls out to /usr/lib/rpm/find-{requires,provides} instead
of /usr/lib/rpm/redhat/find-{requires,provides}, and the non-redhat dep
scripts are broken.

i.e.

$ rpm -ql firefox | /usr/lib/rpm/find-requires | sort > ~/ff-rpm.req
$ rpm -ql firefox | /usr/lib/rpm/redhat/find-requires | sort >
~/ff-rh.req
$ diff -u /home/nicholas/ff-rpm.req /home/nicholas/ff-rh.req
--- /home/nicholas/ff-rpm.req   2006-08-23 15:48:10.000000000 -0700
+++ /home/nicholas/ff-rh.req        2006-08-23 15:48:23.000000000 -0700
@@ -40,6 +40,16 @@
 libm.so.6(GLIBC_2.2.5)(64bit)
 libnspr4.so()(64bit)
 libnss3.so()(64bit)
+libnss3.so(NSS_3.10)(64bit)
+libnss3.so(NSS_3.11.1)(64bit)
+libnss3.so(NSS_3.2)(64bit)
+libnss3.so(NSS_3.3)(64bit)
+libnss3.so(NSS_3.4)(64bit)
+libnss3.so(NSS_3.5)(64bit)
+libnss3.so(NSS_3.6)(64bit)
+libnss3.so(NSS_3.7)(64bit)
+libnss3.so(NSS_3.9.3)(64bit)
+libnss3.so(NSS_3.9)(64bit)
 libORBit-2.so.0()(64bit)
 libpango-1.0.so.0()(64bit)
 libpangocairo-1.0.so.0()(64bit)
@@ -51,9 +61,17 @@
 libpthread.so.0()(64bit)
 libpthread.so.0(GLIBC_2.2.5)(64bit)
 libsmime3.so()(64bit)
+libsmime3.so(NSS_3.2)(64bit)
+libsmime3.so(NSS_3.3)(64bit)
+libsmime3.so(NSS_3.4.1)(64bit)
+libsmime3.so(NSS_3.4)(64bit)
+libsmime3.so(NSS_3.6)(64bit)
 libSM.so.6()(64bit)
 libssl3.so()(64bit)
+libssl3.so(NSS_3.2)(64bit)
+libssl3.so(NSS_3.4)(64bit)
 libstdc++.so.6()(64bit)
+libstdc++.so.6(CXXABI_1.3)(64bit)
 libstdc++.so.6(GLIBCXX_3.4)(64bit)
 libX11.so.6()(64bit)
 libXft.so.2()(64bit)


-- 
Nicholas Miell <nmiell at comcast.net>