Linux Archive - Switching to systemd by default in new installations

On Sun, Oct 07, 2012 at 07:43:13PM +0200, Thomas Bächler wrote:
> Am 07.10.2012 19:29, schrieb Dave Reisner:
> > On Sun, Oct 07, 2012 at 06:49:46PM +0200, Thomas Bächler wrote:
> >> Tom and I discussed this on IRC, so I'll just throw it in here.
> >>
> >> I'd like to make the following changes to our packages:
> >>
> >> * Remove initscripts and sysvinit from the base group.
> >> * Add systemd-sysvcompat to the base group.
> >
> > I'd really like to get rid of the /bin/systemd symlink if we're going to
> > do this. I suppose it can just be part of the news item we post.
>
> Why did you even introduce this symlink in the first place? Why did you
> not remove this symlink _before_ we told everyone to use
> init=/bin/systemd on their command line? If you knew this symlink was
> going to disappear eventually, why not tell everyone to use
> init=/usr/lib/systemd/systemd from the beginning? (Not trying to be
> rude, I really need a history lesson on this.)

Once upon a time, systemd was installed to /bin, and we told people to
use init=/bin/systemd. It seemed like the logical thing to do ;). This
entirely predates the /usr merge and we had no idea that the binary was
going to move to {,/usr}/lib. We had no idea this was coming, but I've
opposed to getting rid of it because it doesn't cost us a whole lot. I
think this is an excellent time to remove it.

> >> As not all packages are equipped with systemd units yet, a compatibility
> >> layer exists: You can install the initscripts package, which does not
> >> depend on sysvinit any longer (and thus doesn't conflict with
> >> systemd-syscompat). A new initscripts installation will come with an
> >> empty DAEMONS array by default. Once you add rc.d scripts to DAEMONS,
> >> systemd will generate compatibility units for those services, or enable
> >> the systemd unit if a unit with the same name exists.
> >
> > This "compatability" layer is still a mess with packages shipping rc.d
> > files which don't match up with the unit file name. I proposed a
> > solution for this in initscripts that involved keeping a static list of
> > exceptions in arch-daemons rather than peppering packages with symlinks
> > full of lies, and it appears that nothing has been done yet. This
> > _must_ to be fixed first.
>
> In the current status, only a small number of people will even need it,
> and they will only specify services which do not have a unit at all -
> and nothing is broken there. I don't really see the problem - can't we
> expect our users to gradually remove the compatibility DAEMONS over
> time? Do we really have to hold their hands?

Apparently we do. I've been against the generator from the start. Force
things to break, and let people who actually care fix them. At a
minimum, we realy need to get rid of the broken symlinks that we're
shipping. You can start/stop/status them by the symlink name, but you
can't enable them, and the message is totally non-descript.

> Can you give a link to your proposed patches? I am really not against
> improving this, I just don't see it as a showstopper.

I never wrote the patch, but maybe I need to if no one else is going to
do it. I can probably find 10 minutes this afternoon to write an RFC
patch.

d