[HEADS-UP] systemd for F14 - the next steps

[Lennart Poettering]

On Wed, 21.07.10 22:13, Chuck Anderson (cra at WPI.EDU) wrote:

> 
> On Thu, Jul 22, 2010 at 03:49:21AM +0200, Lennart Poettering wrote:
> > The logic behind chkconfig is exposed in many ways in the user
> > interface, for example in the chkconfig command line, e.g.
> > commands such as "resetpriorities", and stuff like that.
> 
> I think having some level of command-line user-interface compatiblity, 
> even if not 100%, is important.  "resetpriorities" is probably so 
> rarely used that the systemd version of chkconfig could probably just 
> make it a no-op (unless it was dealing with old sysvinit scripts, in 
> which case it could probably just call through to the old chkconfig).  
> But for basics such as "chkconfig service on|off|--list", there should 
> be compatibility.  Runlevels could perhaps be dealt with by mapping 
> the common cases like 3,5 to the multiuser-target, graphical-target, 
> etc.  Likewise for "service foo start|stop|reload|condrestart" etc.

As mentioned multiple times this is actually what happens all over the
place. We support the runlevels on the kernel  command lines, and init
scripts are "redirected" to systemctl as soon as 

https://bugzilla.redhat.com/show_bug.cgi?id=612728

is merged. And it is on my todo list to add something similar here for
chkconfig, and Jef offered to implement this.

This discussion was was mostly about whether to make this completely
transparent or not. And in contrast to the support for /sbin/reboot and
stuff I was and still am arguing that in the case of the init scripts
and chkconfig while we might execute something that is mostly equivalent
what the user asked for we still should warn him, that this is not fully
equivalent what used to be done. OTOH /sbin/reboot and suchlike are
fully and transparently supported by systemd and there's no reason to
push him to use anything else.

> > Jeez. I guess you cannot be helped. I guess it doesn't help in any way
> > here to mention that we were two steps ahead of you here and provide
> > "systemctl show" which can be used to introspect systemd units in all
> > details and properties in a parsable way. Also, we added "systemctl check"
> > which prints a one line super-short status.
> 
> Well, there is some merit in the already stated argument for having 
> good UI design.  In this example, you could have used long-standing 
> precedent of using -v -vv -vvv (or -q -qq -qqq, or --verbose=N) 
> arguments instead of "status" "show" "check".  Now you've created new 
> lore of needing to know when to use "status" vs. "show" vs. "check", 
> what the differences are between them, and what their order of 
> increasing verbosity is.

Well, I think good UI means that you distuingish computer parsable and
human readable tools. "status" is human readable. "show"/"check" are
computer-parsable.

Human-readable stuff we want to indent and ellipsize to make it easily
readable. Computer-parsable stuff should be neither.

And that's why came up with two commands (and added a third one which is
the same as the other one, but treats the runlevel specially).

Or to turn this around: many folks parse the output of ifconfig. And
that's just wrong on so many levels. We try to do better and actually
provide you with a proper interface for people who want to parse our
output.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.