On Wed, Aug 25, 2010 at 03:27:54PM -0400, Bill Nottingham wrote:
> chkconfig is different, because it's not a 1:1 mapping, and there are
> different semantics involved. I'd like to have it working so that the
> automated uses in scripts/frameworks work (checking whether a service is
> enabled, for example), with the realization that everything it's used for
> isn't going to be supported.
I think that either having chkconfig working fully *or* having an arguably
improved systemd replacement¹ is a blocker. The automated uses should work,
but also these basic end-user/admin use cases (refinements welcome, btw):
- enable a service in its "normal" targets
- disable a service in all targets
- enable/disable a service ("unit" in systemd-speak) in a given target
with one easy command
- nicely list all units that will be enabled in a given target
(recursively, with some thought put into the formatting)
- nicely list all targets in which a given unit will be enabled
(with the option of only showing targets which are sensible
for isolate/switch-to).
I don't think this is an onerous requirement, because systemctl already does
the first two things, and does the last two are almost there (just with no
pretty output). The middle thing, as I understand it, Lennart would rather
people do by manually creating and moving symlinks, but I think there's a
pretty good case for having a user-interface to do it.
(That case being: people used to administer sysvinit runlevels by
manipulting symlinks, and it sucked. Then we got chkconfig as standard, and
it was much nicer.)
And in the "or" case, there needs to be really good release notes, offering
tasty, tasty cake. That is:
1) explaining that the change is necessary because the semantics don't
match exactly,
2) giving a concise explanation of why the new semantics are better
3) showing off the command and how to use it
4) showing something cool this give you that chkconfig doesn't offer.
1. as discussed here:
http://lists.fedoraproject.org/pipermail/devel/2010-August/141713.html
--
Matthew Miller <mattdm@xxxxxxxxxx>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
