> Am Montag, 9. Juni 2003, 19:51:41 Uhr MET, schrieb Stefan van der Eijk: >> Q: will every time a .so file gets move from a lib to a lib-devel >> package these questions be asked? 'cause then I give up. Proof should >> go the other way --> the person bringing up the issue should present >> proof.
> you always have to test the new package when you move files around > between library and devel package. I told you, it's tested. Or please tell me how I am suposed to test this case. >> I think nothing has been broken. It's a real versioned .so file. Other >> packages need this .so file: > >> $ urpmq -R libguilereadline.so >> libg-wrap1-devel >> libguile10-devel >> libguile12-devel >> libguile-gtk-1.2_0-devel >> >> and yet other packages need the versioned .so.X. file: >> >> $ urpmq -R libguilereadline.so.0 >> libguile10-devel >> libgnucash0 >> gnucash-hbci >> libguile10 >> libguile12-devel >> libguile-gtk-1.2_0-devel >> beast >> libg-wrap1-devel >> penggy >> gnucash >> libgnucash0-devel >> guile-compat >> gnucash-ofx >> glame >> >> It's not a plugin or something like that... > > It seems you are right. But just because it's in /usr/lib this doesn't > mean it can't be a plugin. True. > I've thought a bit about the libltdl problem: I guess I've mixed this up > a bit, the important thing for libltdl is the presence of the .la file, > it doesn't need the .so symlink. Libltdl provides some kind of > intelligent dlopen, so you can use it to open a plugin library with > something like 'open(libfoo)', it will parse the libfoo.la file and open > libfoo.so.3. So the .la file is needed in the lib package, and not in the -devel package? We should write up on this and enforce it (rpmlint). CU Stefan
