[systemd-devel] [PATCH] systemctl: print unit package in status

Lennart Poettering lennart at poettering.net
Thu Dec 18 12:23:27 PST 2014


On Thu, 18.12.14 18:48, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl) wrote:

> On Thu, Dec 18, 2014 at 11:19:22AM -0500, Spencer Baugh wrote:
> > Quoting Jóhann B. Guðmundsson (2014-12-18 04:08:32)
> > > 
> > > On 12/18/2014 04:00 AM, Spencer Baugh wrote:
> > > > When printing the status of a unit, open a connection to the session bus
> > > > and query PackageKit for the package that the unit file belongs
> > > > to. Print it if PackageKit knows.
> > > 
> > > There are gazillion package manager in the wild 
> > 
> > PackageKit is a generic interface to the local package manager, used
> > by all the major distros and desktop environments. It's installed by
> > default on any normal desktop/laptop. So this is different from
> > hardcoding a call out to yum or apt.
> Yes, packagekit is generic and widespread enough.
> 
> > > and this will 
> > > significantly delay the output of the status command which makes this 
> > > something you should be carrying downstream.
> > 
> > It adds 800ms to the output on my system. Still, adding a command line
> > flag to enable/disable this behavior would be good. If other
> > slower-than-usual operations are added, we might want to
> > enable/disable them with the same flag.  Suggestions on a flag name
> > that's appropriate for that behavior?
> I think you should make it opt-in, with a command-line switch (--show-package ?).
> In some cases it can be very useful, but most of the time it would
> be just a slow down. If the switch is used, and packagekit does not
> work, then this should cause a warning or an error though.

Well, humm. Not convinced this is a good idea. I mean, showing it by
default is not a good idea, given how slow this is. But hiding it
behind some switch makes it mostly useless, as it's not any more
discoverable then invoking "rpm -qf" on the fragment path would be.

Also, in general I am not really convinced that this kind of hookup
with external daemons that are not part of systemd itself is really a
good idea. It's the wrong way around I think. I mean, we so far had
such a weird dependency on the dbus daemon, and we are just about to
get rid of it, but doing the pkgkit hookup adds a new one back in
where our base OS starts using components way up the stack...

Lennart

-- 
Lennart Poettering, Red Hat


More information about the systemd-devel mailing list