Yes. good idea. I think this makes sense.- changing the .so Provides / Requires to .dso (or something else, but not ..so). I *urgently* suggest that this is done before the next release. Once this is put into a release, it will need to stay and be maintained. Why does this need to change? Well, because at this moment we can't really differentiate between .so devel dependencies (http://eijk.homelinux.org/~stefan/rpm_devel_dependencies.html) and _other_ .so dependencies. The one example I've seen is:
$ rpm -q --provides libdb3.3-3.3.11-14mdk db3 = 3.3.11-14mdk libdb-3.3.so libdb3.3 = 3.3.11-14mdk
While libdb3.3-devel (when it is rebuilt) will _also_ provide libdb3.3.so:
$ ~/test06.sh libdb3.3-devel libdb3.3-devel Provides: libdb-3.3.so libdb3.3-devel Provides: libdb_cxx-3.3.so libdb3.3-devel Provides: libdb_tcl-3.3.so
This screws up the whole model. I had not taken this into account, but now that I've come across it, I think we need to change this, _before_ a release is made. What I'm proposing is that this is changed to:
$ ~/test06.sh libdb3.3-devel
libdb3.3-devel Provides: libdb-3.3.dso libdb3.3-devel Provides:
libdb_cxx-3.3.dso libdb3.3-devel Provides: libdb_tcl-3.3.dso
Lets at least come up with a sane name. Even though dependencies are not supposed to be human redable, i dont think it is not wise to make it appear that it is in fact providing a file that doesnt exist.
Suggestions (i have no idea about any other limitations) libdb-3.3.so-devel libdb-3.3.so(devel) etc...
Stefan
smime.p7s
Description: S/MIME Cryptographic Signature
