>> >> Yes. >> >> > So what should happen if a package has a build requirement on a >> specific version of a library (e.g. libfoo.so.1.0.7)? >> Then you'll need to specify this specific BuildRequires in the .spec >> file, with the package name. >> >> BuildRequires: libfoo-deve >=1.0.7 or something like that. > I suppose this should only happen like your example with a > or >=.
Yes. >> > Or is this impossible unless a versioning scheme like with db3 & >> db4 >> is used? If it should work you're right to want different dependency >> names. >> We're seeing that more and more of these dependencies have version >> numbers in them for the major part. Good example are the >> glib1.2-devel and glib2-devel packages. > > Yes, but here libglib-2.0 is a different library, no versioning is > done on the -x.y part. Except that there is no libglib-1.2.so but > instead only a libglib.so. True. That is the file(name). Please try out: # objdump -p libglib.so | grep SONAME SONAME libglib-1.2.so.0 Then we chop off everything behind \.so which gives the name of the Provides, perhaps with something added (-devel) to show that it's a -devel dependency. > It's all consistent though, a library provides a file > where the SONAME matches the filename, The filename shouldn't play a role. It doesn't say anything. If you would rename it, then the Provides stays the same. > and zero or more symlinks for > linking against it during build-time. Maybe this has been suggested > before, but what's against naming the provides and requires for a > library libfoo.so "libfoo-devel" so if you have libfoo-1.2.so you get > "libfoo-1.2-devel"? libdb4.0-devel should then get (amongst others) > provides: libdb-4.0-devel libdb-4-devel libdb-devel >From a human point of view this may be possible. But I wonder if it can be implemented in the find-[provides|requires] scripts. If you beleive it may work, feel free to try. I'm willing to test it. >> >> >Stefan, I think the problem isn't the naming of the requirements, >> >> >> Well, you can't disagree that using the ".so" is at least >> confusing. It's very difficult to tell where it came from. >> >> >> If we would change the naming, then even _if_ packaging is >> incorrect, it wouldn't fool the system --> and that's one of my main >> motivations to change the naming. >> >> >> >it's the method. We shouldn't be chopping off the bit that >> follows >> >> > .so, we should be finding the file that links to the library >> listed. >> >> >> I don't follow you here... >> >> > For a regular dependendy to libdb-4.0.so one might expect a -devel >> dependency on libdb-4.so, or even libdb.so. Note that libtool >> doesn't get this right either (or does it use the same code?), >> judging from /usr/lib/libdb-4.0.la: >> > library_names='libdb-4.0.so libdb-4.0.so libdb-4.0.so' >> > >> > At least, I would expect it to be: >> > library_names='libdb-4.0.so libdb-4.so libdb.so' >> >> Yes, this is confusing. And I don't intend to these inconsitancies >> :-) As unix is consistanly inconsistant. >> >> I'm aiming to make the -devel dependencies smart enough that it won't >> be fooled by these inconsitancies. By introducing a different naming >> scheme the confusion is over... > So you want indeed distinguish between a -ldb, a -ldb-4, and a > -ldb-4.0? These should all get different dependencies so you get the > correct behavior if/when a db4.2 or db5.0 gets released. Yes, for the db's this will be the case. In my e-mail I was just proposing to change the naming of these dependencies, not change the whole mechanism. I think the mechanism has proven that it is correct. I think we should stay on-topic and discuss how to name it, or better: make a descision to what the naming will be changed (my preference is .so-devel). A discusion on the mechanism of the -devel dependencies should be done in a seperate thread. And please, when proposing something, back it up with actual code so we can test it (at least something like the test script on the webpage below). The document about rpm -devel dependencies can be found here: http://eijk.homelinux.org/~stefan/rpm_devel_dependencies.html I will move it to Mandrake's wiki so other people can also add their input to it. regards, Stefan
