systemd acceptance, packaging guidelines (was Re: systemd and changes)

Matthew Miller mattdm at mattdm.org
Wed Aug 25 20:15:59 UTC 2010


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 at mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences


More information about the devel mailing list