[HEADS-UP] systemd for F14 - the next steps
Simo Sorce
ssorce at redhat.com
Fri Jul 23 03:25:31 UTC 2010
On Fri, 23 Jul 2010 02:43:45 +0200
Lennart Poettering <mzerqung at 0pointer.de> wrote:
> On Thu, 22.07.10 20:40, Lennart Poettering (mzerqung at 0pointer.de)
> wrote:
>
> >
> > On Thu, 22.07.10 08:05, Simo Sorce (ssorce at redhat.com) wrote:
> >
> > > > to make real; give reality to (a hope, fear, plan, etc.).
> > > >
> > > > but its seems quite an abstract term to associate reality with
> > > > an abstract computer object.
> > >
> > > Dave, I am not a native speaker, but I have the exact (or may be
> > > even worse) problem. For as much as I try the syntax there is so
> > > obscure I cannot "realize" what it means *at all*, just by
> > > looking at it.
> > >
> > >
> > > Lennart, "realize" really is a bad bad bad choice, please consider
> > > changing it while there is still time.
> >
> > Kay and I have discussed this now. We agreed to fold systemd-install
> > into systemctl entirely, and replace --realize by --now. Also, we'll
> > drop some of the options --realize had, and always imply that the
> > init system configuration shall be reloaded after all changes took
> > place. This basically means that this
> > is what will be done in %post in the general case:
>
> Kay and I discussed that even further now and decided to scrap --now
> entirely now. There's little reason left to keep this as flag around.
> I think it is more descriptive to do this on %preun:
>
> systemctl stop postfix.service
> systemctl disable postfix.service
>
> then it would be to do this:
>
> systemctl disable --now postfix.service.
>
> Especially for "enable" this is even more the case, since depending
> on the case you might or might not want to restart, or reload the
> service on package upgrade. For example, restarting D-Bus or the
> gettys on package uprgade would be a really bad idea, but restarting
> ntpd might be a good idea. Given that packagers would have to
> specifiy anyway whether they want to reload, or restart or nothing at
> all a service on upgrade we think it would make more sense if they
> simply delcare their choice explicitly and do either one fo this in
> %post:
>
> systemctl enable foobar.service
> systemctl try-restart foobar.service ### restart if running
>
> or:
>
> systemctl enable foobar.service
> systemctl reload foobar.service ### reload if running
>
> or just:
>
> systemctl enable foobar.service
>
> or, for debian folks which want to start services after package
> installation:
>
> systemctl enable foobar.service
> systemctl restart foobar.service ### restart if runnning,
> start if not running
>
> I think this scheme is really simply now, as the operations issued are
> first class commands, and no switches necessary. Also, the verbs here
> are 1:1 from the LSB specs, and hence should offer no surprises to
> anybody.
>
> Everybody happy?
I am personally quite happy, this looks much much better.
Juyst one very minor nitpick, why
systemctl enable foo.service
instead of
systemctl enable service foo ?
And of course
systemctl enable socket bar
etc...
Simo.
--
Simo Sorce * Red Hat, Inc * New York
More information about the devel
mailing list