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

[Rudolf Kastl]

2010/7/15 Simo Sorce <ssorce at redhat.com>:
> On Thu, 15 Jul 2010 16:59:40 +0200
> Lennart Poettering <mzerqung at 0pointer.de> wrote:
>
>> Because it reverses everything.
>
> And this is a problem because ?
>
>> I.e. generally we have the rule that "native configuration breaks
>> legacy configuration".
>
> Who's "we", what is the rationale of this rule ? Looks like it is a
> rule made to break things on upgrades. Most upstream I know have the
> inverse rule. Do not break things unless it is *necessary*.
>
> I do not see why it is necessary to break here.
>
>> However, to make the inittab stuff useful we'd
>> have to turn that around, and say that "legacy breaks native". Why?
>> Because the /etc/systemd/system/default.target symlink is created by
>> the rpm in all cases and would hence make the inittab ignored anyway.
>>
>> If I added inittab parsing support even when keeping "native breaks
>> legacy" around, then inittab would matter only if the default.target
>> symlink doesn't exist. We could certainly inform the user to delete
>> that symlink, via some blurb in inittab, however, if he goes and
>> deletes it, wouldn't it be much easier to just fix properly and to
>> the right boot target, and have a future-proof system?
>>
>> i.e. isn't this:
>>
>>     # vi /etc/inittab
>>         ... user reads the blurb and changes a line, exits
>>     # rm /etc/systemd/system/default.target
>>
>> really that much better in your eyes, than this:
>>
>>     # vi /etc/inittab
>>         ... user reads the blurb, quits right-away
>>     # ln
>> -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target
>>
>> I don't think it is...
>
> You are assuming a human is doing these changes, in many cases it is
> install (kickstart) scripts. And keeping compatibility means an admin
> does not have to start making big exceptions because a subset of
> machines now start needing a different way to change it.
>
> You can also add a blurb in inittab that says something about removing
> the init line, and how this will activate the beautiful systemd
> mechanism to handle runlevels.
>
> - Then admins can choose which one to use.
> - Does not break on upgrades
> - Does not break anaconda and anaconda devs have the time to do the
> change to stop installing an inittab in new installations while keeping
> what is there working on updates without having to do special case
> handle. Otherwise anaconda will have to care about handling this change
> too on distro upgrades.
>
> And so on.
>
> Simo.
>
> --
> Simo Sorce * Red Hat, Inc * New York
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>

also there is the fact that current init scripts usually do alot
more... like adding configtest (a generic way of syntax checking
before trying to restart the daemon to avoid downtime with last minute
changes that cannot be tested on another machine for one way or
another...) and i also hope that this time restarting a service plays
nice with using cluster software (restarting returns exit 0 if the
daemon starts successful no matter if the shutdown failed.)

kind regards,
Rudolf Kastl