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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
