Hi,

The library packages don't depend on the service, but they are a wrapper
around the DBus API. This means that you can write a program using
Geoclue and it'll fail at runtime because the service isn't installed so
it can't be bus activated.

I think probably libgeoclue-2-0 should depend on geoclue-2.0. (Might
need to make geoclue-2.0 M-A: foreign?)

Cheers,

On Tue, 06 Jun 2017 18:03:28 +0100 Iain Lane <laney@debian.org> wrote:

 > Hi,

Hello,

 > The library packages don't depend on the service, but they are a wrapper
 > around the DBus API. This means that you can write a program using
 > Geoclue and it'll fail at runtime because the service isn't installed so
 > it can't be bus activated.
 >
 > I think probably libgeoclue-2-0 should depend on geoclue-2.0. (Might
 > need to make geoclue-2.0 M-A: foreign?)
 >

The main problem is that adding the dependency will create a dependency
loop. Apparently the daemon package is already dependency against
libgeoclue-2-0

Le 14/07/17 à 16:26, Laurent Bigonville a écrit :
Apparently this is due to the where-am-i demo program, I guess that one
could be moved to an other -demo package

To avoid making a new package: put it in -dev maybe? Or don't install
it? I guess it's most interesting for developers to learn to use the
API?

Ok, I suppose -dev would break M-A: same, but maybe putting things in
the multiarch libdir would be good anyway.

Cheers,

The where-am-i program was indeed moved to a -demo package, which should
unblock this bug.

I proposed marking the dependency here:
https://salsa.debian.org/freedesktop-team/geoclue-2.0/-/merge_requests/17