Control: reopen -1
Control: severity -1 critical
Rationale: breaks unrelated software
Rationale: breaks whole system
The current state causes a forced init switch, even on initless containers
and machines that use any other init. This includes machines that systemd
is unable to boot on (I personally possess one, and there are multiple
others reported), machines where systemd fails to work adequately on
(examples including btrfs raid, bind mounts, etc), the admin's scripts
assume sysvinit openrc or runit (such as directly invoking /etc/init.d/xxx
which might be unrecommended but it has worked so far on that machine, etc).
And this change breaks all those systems.
It also breaks inits/rcs other than systemd.
Thus, this bug matches two definitions of severity:critical.
Michael, you once again dismissed a bug that breaks non-systemd systems,
despite the fallout being obvious to predict, you having personally
witnessed a number of similar bugs, and a fix being easy. This is not fun,
goes against the recent GR (by making alternatives hard to use), and is a
continuation a pattern where you wishlist+wontfix+close such "non-bugs" as
making apt unable to run. Please stop.
In this case, apt's behaviour takes even a seasoned DD quite a bit of
research to work around udev's new dependency, as apt doesn't make it
obvious what the culprit is.
> This dependency is autogenerated by debhelper, as udev ships a tmpfiles
> config. So the udev package can't do anything about it and subsequently
> I'm going to close this bug report.
I don't believe a developer of your skills would even need to refer to a
man page to find out how to correct an autogenerated dependency.
> A couple of remarks here:
> systemd-tmpfiles is a virtual package and Debian policy
> recommends/requires that a real package is listed as first alternative
> as otherwise apt might pick a random provider. So by dropping the
> alternative, we'd have a policy violation, which is possibly RC.
No, that's only an "if-then". And if you want a strict conformance to the
Policy, you use a virtual package name that's not on the list, which is
forbidden.
And if you want a real package first, -standalone is a clear winner here.
All systems you appear to care about already have systemd installed. On the
other hand, systems that do NOT have systemd, are either containers or
bare-metal machines that have been intentionally configured to not have
systemd, for one or another reason.
Thus, if after the initial debootstrap, systemd is not present, in all cases
the preferred default is -standalone. The order doesn't matter if an
alternative is already present.
The table of possible cases:
systemd | standalone:
systemd -> no op
sysv -> forced init switch
initless -> forced init install
standalone | systemd:
systemd -> no op
sysv -> standalone
initless -> standalone
Meow!
--
⢀⣴⠾⠻⢶⣦⠀ Ash nazg durbatulûk,
⣾⠁⢠⠒⠀⣿⡁ ash nazg gimbatul,
⢿⡄⠘⠷⠚⠋⠀ ash nazg thrakatulûk
⠈⠳⣄⠀⠀⠀⠀ agh burzum-ishi krimpatul.
