On Fri, Feb 06, 2004 at 04:43:41PM +0100, Eduard Bloch scribbled: > #include <hallo.h> > * Greg Folkert [Fri, Feb 06 2004, 10:29:33AM]: > > > > What would be a good way to deal with the situation? Is it sufficient > > > to let both packages conflict with each other? > > Zounds.... This sounds like a job for our Super Hero:\ > > "update-alternatives" > > > > And having both packages use unique names and then you choose your > > alternative. > > This calls for trouble since you have a management layer above > (ldconfig). > > IMHO it would be better to mediate between upstream authors. > Let them choose different SONAMEs, idealy they should modify the base The thing is, the spidermonkey upstream uses no SONAME at all. In fact, their shared library building support is quite poor. I hacked the makefiles to build a normal shared library with the soname and the correct naming format, but it's far from being an upstream thing. I think I could submit my changes to the upstream and try to talk about the way for various js libraries coexist on one system. > name. Or they could find an agreement to use even / odd soname numbers > so the applications would never look for the wrong library. Though, -dev > packages would still need to conflict with each either and have > different names. That was precisely why I decided to rename the spidermonkey libraries. It just seemed to be the best compromise, especially that it seemed that not much software depends on the shared library in a standard location. Another alternative would be to put both libraries in some directory underneath the /usr/lib dir and have the applications use wrappers setting LD_LIBRARY_PATH. That solution, however, would cause problems with libraries that'd link with either of the JS shared objects. regards, marek
Attachment:
signature.asc
Description: Digital signature