On Thu, 15 Jul 2010 16:59:40 +0200 Lennart Poettering <mzerqung@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
