Hi!

On Sat, 2017-04-22 at 09:07:01 +0200, Johannes Schauer wrote:
> Package: dpkg
> Version: 1.18.23
> Severity: wishlist

> I recently hacked on a series of packages when I noticed that
> dpkg-shlibdeps emitted the following dependency for my new packaging of
> src:linphone:
> 
> libbellesip0 (>= 1.6.1), libbellesip0 (<< 1.6.0)
> 
> The reason for that was probably that the source package libbellesip0
> came from had debian/libbellesip0.symbols file which enforced the
> "libbellesip0 (<< 1.6.0)" version restriction while at the same time the
> symbols indicated that "libbellesip0 (>= 1.6.1)" was needed. From
> debian/libbellesip0.symbols:
> 
> libbellesip.so.0 libbellesip0 #MINVER#, libbellesip0 (<< 1.6.0)
> [...]
> belle_sip_body_handler_begin_recv_transfer@Base 1.6.1
> belle_sip_body_handler_begin_send_transfer@Base 1.6.1
> [...]
> 
> I think there are several places here that could emit some sort of error
> message. One is when building src:linphone, dpkg-shlibdeps could
> probably check whether the final dependency string it puts into the
> substitution variable is satisfiable at all and emit a warning or throw
> an error if that's not the case.

Hmm, I'm not sure this one is actionable. There's nothing requiring a
package to define dependencies on itself, so while the .symbols will
be present when the shared library package is present, and while we
could check the satisfiability for that one, nothing says all injected
dependencies are going to be present.

> Maybe another thing that could be done would be to warn if a *.symbols
> file is seen with such a dependency restriction as showcased above. But
> I don't know if it's possible to do this reliable or if there are cases
> where this will lead to false positives.

This one seems too specific, and would probably need to check each
individual symbol to see whether it matches only on any such constrain on
the binary package itself, including any Provides from any binary package
generated by the same source, etc.?

My feeling is that this might be too much complexity for something
that is simply a bug, which should be easy to spot at installation
time? I'm happy to consider patches, but I'm not sure I'm going to be
working on this myself. :)

Thanks,
Guillem

Reply via email to