>> Hi Frederic, >> >> Thanks for putting some of my suggested changes through, can we discus >> the other ones? >> >> - remove BuildRequires: automake. this one is quite important, since >> it blocks autoconf2.5 from being installed with slbd. It actually is >> an redundant BuildRequires, since it is already Required by rpm-build. >> Which, together with basesystem (and BuildRequires) are the minimum >> requirement for building rpms. See also: >> http://qa.mandrakesoft.com/twiki/bin/view/Main/BuildRequires >> >> - 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:
> But is this a packaging error, or an error with the model? This is a flaw in the naming model. Because we (I?) assumed it would be OK / decided to call those -devel Provides / Requires ".so". If I would have called them ".cow" or ".fish" (or anything else that doesn't exist in rpm dependency land) then there wouldn't be an issue. In this case, it's unfortunate that libdb3.3 Provides the same Provides that is caculcated by the -devel dependencies in libdb3.3-devel. Also, you can't destinguish them... as .so dependencies already existed. If we would have called them ".fish" then you would know --> ".fish" is a -devel dependency. > If this is the only occurence of this, then I think it's a packaging > bug, influenced by the fact that the dbX file names don't follow > standards (were is libdb-3.so.3?). Perhaps. But I don't think so. I guess that what happened in libdb3.3 is valid. We just need to invent a _different_ naming scheme for our (new) -devel dependencies. >> $ ~/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 > I don't agree with providing something that looks like a filename, when > it is not a filename, it will just confuse people. I would propose for > "virtual-devel-libdb-3.3.so" We could do that, but the name is quite long. How about ".dso"? short for "devel .so" or "dynamic .so"? or ".vso"? Regards, Stefan
