[PATCH] Revert 5ce97e6f22fd25279793fbc75211d2e86413ae73 from ConsoleKit

[Michael Biebl]

2008/1/31, William Jon McCann <mccann at jhu.edu>:
> Hi,
>
> On Jan 30, 2008 11:17 PM, Michael Biebl <mbiebl at gmail.com> wrote:
> > here is what happens when you install libpolkit only:
> >
> > console-kit-daemon --debug --verbose
> > console-kit-daemon[14886]: DEBUG: Debugging enabled
> > console-kit-daemon[14886]: DEBUG: initializing console-kit-daemon 0.2.7
> > ...
> > console-kit-daemon[14886]: CRITICAL: cannot initialize libpolkit
> > console-kit-daemon[14886]: GLib-CRITICAL: g_async_queue_unref:
> > assertion `queue->waiting_threads == 0' failed
>
> That may be a bug or misconfiguration.  Can you investigate the
> precise reason why this is failing?  PK has a debug mechanism that may
> give you more information.  My guess is that you may be missing some
> of the necessary configuration files.

libpolkit adds an inotify_watch on /etc/PolicyKit/PolicyKit.conf,
/var/lib/misc/PolicyKit.reload and /usr/share/PolicyKit/policy/ and
fails if not present.

/etc/PolicyKit/PolicyKit.conf ist part of  the (Debian) policykit package.
Shipping the configuration file in libpolkit is not an option, because
it would make it impossible to co-install libpolkit versions with
different sonames, which makes smooth library transitions impossible.

>
> > I.e. the ConsoleKit package will require the complete PolicyKit
> > package to be installed in order to function properly.
>
> I think you'll find that isn't true (once you investigate the above).

See above.

> > Otoh, a package using PolicyKit (like gnome-system-tools) will fail to
> > function if the complete ConsoleKit package is not installed and
> > console-kit-daemon is not running:
>
> This is a run-time requirement.  Not usually what we refer to when
> we're talking about package dependencies.

I'm not sure how you handle package dependencies in Fedora, but if
packages have runtime dependencies, these relationships are reflected
by the package dependencies.
E.g. strictly speaking the hal daemon only has a (link) dependency on
libdbus (which is automatically added by the Debian build tools), but
the Debian hal package has a dependency on the dbus package (manually
added), because it wouldn't be really functional otherwise. I don't
think Fedora handles that differently.

> > I hope you see the problem (the circular dependency) now. But I won't
> > beat this dead horse any longer and instead try to be constructive.
>
> This is still not a what we usually consider a circular dependency.
>
> ConsoleKit requires libpolkit to *build*.  Polkit-DBus uses ConsoleKit
> over D-Bus when it *runs*.

I was talking about runtime dependencies here.

> > What do you think about moving the system stop/restart functionality
> > into a separate D-Bus system service, which claims
> > org.freedesktop.System and provides the Stop()/Restart() methods. This
> > daemon could use PolicyKit without any side-effects and would be
> > auto-started on-demand using D-Bus system activation.
> >
> > This would be the cleanest approach imho. What's your take on this?
> > Would you accept a patch for this?
>
> And in your view what is the advantage of this approach?  And what are
> the disadvantages?

advantages:
- CK doesn't have to link against libpolkit. Makes it possible to
- Do one task and do it right, as the Unix saying goes.
- Avoids complexity in CK. (CK is a long running daemon, the daemon I
described above doesn't need to and can self terminate after a
timeout).
- This means less memory usage.
- CK remains true to its mission, which is to provide information
about users, sessions and seats.
- It's easier to grasp, what component does what. The design is
clearer (subjective)


disadvantages:
- Having a separate binary means a separate package. This means more
packaging work for distributors.

Cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?