[PATCH] Revert 5ce97e6f22fd25279793fbc75211d2e86413ae73 from ConsoleKit

[William Jon McCann]

 On Jan 31, 2008 1:56 AM, Michael Biebl <mbiebl at gmail.com> wrote:
> 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.

That's what I suspected.  These are required by libpolkit.

> /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.

If we are actually looking for solutions... then perhaps something
like polkit-common would work?

> > > 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.

Yes this is indeed incorrect.

> > > 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.

In my view, one of the main points of D-Bus was to get rid of this
practice.  The bus is a hub and inter-dependencies are the norm.
There is no need to require specific packages to fill the well known
name (service) role.

> > > 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.

Even then this isn't really accurate.  Because the dependency is only
on the existence of a provider of the D-Bus interface name - not a
specific package.

> > > 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

This is not an advantage only an implementation detail.

> - Do one task and do it right, as the Unix saying goes.

I think one can argue that moving restart/shutdown functionality from
GDM/HAL to ConsoleKit is actually doing just this.

> - 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).

No more complex than anything else in ConsoleKit.  Also removing this
complexity from GDM and HAL arguably does have some benefit.

> - This means less memory usage.

Prove it.  Also you'll need to start a new service in order to reboot
- that seems risky.  In some cases you'll have two daemons instead of
one.  You'll also need access to the logging functionality in
ConsoleKit.

> - CK remains true to its mission, which is to provide information
> about users, sessions and seats.

That is a part of the mission.  In fact, you may notice here that we
haven't even started providing information about users.  I was
wondering why I've never been called out on that.

> - It's easier to grasp, what component does what. The design is
> clearer (subjective)

org.freedesktop.ConsoleKit.System.Restart seems pretty clear to me.  I
think we really do want this functionality pretty low in the stack.
There is clearly some affinity to both the init system and the wtmp
logging system.  Relying on an init system providing a D-Bus interface
is problematic for a few reasons.

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

- Another point of failure
- Possibly more memory use
- Difficulty synchronizing log events with ConsoleKit
- Have to go over the bus for information from ConsoleKit (rather than
getting it in process)
- Slower to start up and respond
- ConsoleKit will then have an implicit run-time dependency on this
tool to update the log file.
- Unnecessary

Jon