[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Javascript libraries in debian

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.



Attachment: signature.asc
Description: Digital signature

Reply to: