Lennart Poettering (mzerqung(a)0pointer.de) said:
Well, I don't think we want to support both. I believe F14 should
be
systemd and only systemd, but we want the option to revert to upstart
should that not work out.
I am very much interested to get upgraded systems to use systemd as
well, which is why I'd really like to go the Obsoletes way, and use a
versioned Obsoletes, so that we can switch back to upstart if we want to
by another versioned Obsoletes, but this time from upstart. (which is
exactly what James Antill proposed in his mail)
Or in other words: I'd like to make this switch for the whole distro,
not leave it to the individual machines.
So, unless there is really strong opposition to the Obsoletes approach
I'd go on and do the switch?
If we're at the... 95% coverage case, I guess. What I don't want is that
machines suddenly stop booting with no recourse other than init=/bin/bash
and manual recovery. There are some side cases that would be nice to either
have working, or documenting that they're not done yet (serial consoles,
assorted other things.)
> I suspect the biggest issue here is confined daemons, as they
may
> not have permissions to create their own directories in /var/run or
> /var/lock once they've been started. Unfortunately, it's the sort of
> flag day that we really can't do unless everything in our tree is fixed.
Well, a temporary and kind of ugly fix could be to add lines like the
following into the systemd service files for these services.
ExecStartPre=-/bin/mkdir -p -Z foo_t /var/run/foo
Or something like that. And for service which continue to use SysV
scripts something similar is easily thinkable in the init scripts.
Hardcoding foo_t is bad if they ever switch policy (MLS, etc.). But
it is an option.
Bill