Re: Bug#631669: liblwt-ocaml-dev: undefined references to libev
Hi!
I've read the bug report for some context. Something unrelated to
this query I'd like to point out is that there's really nothing
inherently wrong with having more than one SONAME installed for the
same shared library, and having a single libfoo-dev. If libfooN and
libfooN+1 were not co-installable that would make transitions very
painful.
On Fri, 2012-12-07 at 11:46:51 +0100, Stéphane Glondu wrote:
> Le 26/06/2011 17:47, Ian Zimmerman a écrit :
> > So yes, I'd say that the fact the dependency is too loose to catch this
> > pernicious problem on a system configured this way is a bug. (I'm not
> > asking for "support" beyond fixing bugs, though) ;-)
>
> In my opinion, the versioned dependency to libev-dev in liblwt-ocaml-dev
> should be filled automatically, the same way it is for liblwt-ocaml. But
> I don't know how to do it. dpkg-shlibdeps doesn't seem to be designed to
> work this way. If so, I would say the bug is on dpkg-shlibdeps's side;
> however it looks like a corner case, whose fix looks difficult and
> intrusive...
I don't think this should be solved by dpkg-shlibdeps, because this
kind of dependency (in most cases) does not involve directly a shared
library package, the problematic relationship is between packages
providing static libraries and headers (even though the roo cause is
that the dynamic library package might be out of sync, AFAIUI the
ocaml case).
The current way to solve this kind of issue is by using a substvar
computed from the debian/rules file.
> I've put debian-dpkg in CC. Let's see if someone there has a suggestion.
I think this could be made easier to solve with something similar to
what's requested in #689062. If so, I'll work on a syntax proposal for
a new substvar.
Thanks,
Guillem
Reply to: