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

[Simo Sorce]

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