Re: systemd-fsck?
On 9 May 2014 23:50, Russ Allbery <rra@debian.org> wrote:
> Bas Wijnen <wijnen@debian.org> writes:
>> On Fri, May 09, 2014 at 10:37:03PM +0200, Tollef Fog Heen wrote:
>
>>> It and upstart (and any other providers of /sbin/init) should also grow
>>> critical debconf warnings if you install them and you were previously
>>> using systemd as your init so it's symmetric.
>
>> Nobody is suggesting that systemd should give you a critical warning
>> when you try to install it. The problem people are having, is that it
>> suddenly installs itself without the user trying. When sysv init or
>> upstart do that, they should get critical warnings as well. But better
>> yet, they shouldn't do it. And neither should systemd.
>
> The same issue that leads to systemd being installed could well lead to
> one of the other init systems being installed for the same reason: some
> piece of software integrates with only one init system and Depends on it.
> If we can avoid that situation, great -- portable software is always
> good. But belt and suspenders: we should also prepare for that situation
> and ensure that any switch of an init system via package installation
> results in a critical debconf warning so that no one is caught by
> surprise.
>
> This has the advantage of future-proofing against any later change of init
> system, letting us reuse the mechanisms that we put in place for this one.
>
When sysv-init was essential, installing upstart required to type
"Yes, do as I say!". Which is even higher than a critical debconf
prompt.
Users that already have installed upstart, instead of sysv-init,
should upon upgrade stay with upstart installed and running as pid1,
without any prompts.
Similarly users that already have installed systemd, should stay on
systemd without any prompts.
Users of sysvinit, are of two categories, those that "reverted to or
wish to stay with sysvinit" or those that "simply use the default".
It is desired to migrate "simply use the default" to the new default,
systemd, if that is possible.
As far as I understand, for sysvinit users that means upgrade paths
possible are:
* sysvinit + systemd-shim (assuming common-cases that something wants
to use, e.g. logind)
* systemd
I don't think any sets of provides / alternative dependencies
ordering, will give us ability to ask a question upon "apt
full-upgrade" which of the two upgrade paths to take for current
sysvinit users?!
Thus, interim, until we have a mechanism to ask what to do on
upgrades, maybe sysvinit/sysvinit-core should gain a (bogus)
dependency on systemd-shim?
--
Regards,
Dimitri.
Reply to: