Re: Proposal: Reaffirm our commitment to support portability and multiple implementations
[I purposefully abstained in participating in this discussion so far, as I
have quite strong views, and I hoped it will stay mostly civilised. But
alas, last developments seem to fails these hopes. Thus, let's help Guillem
improve his proposal.]
On Sat, Nov 30, 2019 at 02:11:56PM -0500, Sam Hartman wrote:
> >>>>> "Bdale" == Bdale Garbee <bdale@gag.com> writes:
> Bdale> I find this really appealing as a higher-level statement of
> Bdale> values and intent, but unfortunately, I don't think the text
> Bdale> does anything to help resolve the problems that Sam set out
> Bdale> to try and tackle with this GR.
>
> I concur with Bdale and Russ. If this option wins I find that I
> wouldn't know how to go forward. [...]
> This issue gives no guidance on the sorts of issues that I and the
> policy editors are facing. This option provides no guidance on how to
> approach the patterns of behavior that Ian and I have seen on our lists.
I agree. There are statements but no clear guidance. Thus, I'll list
problems in the current state of Debian in regard of systemd in particular:
* there's a lot of use cases where systemd fails[1]. This makes it unfit
for being the sole init+rc of an universal operating system.
* patches fixing non-systemd regressions are routinely ignored[2]
* changes I view as done with spite, which bring no or negligible benefit to
systemd yet large detriment to other rc systems[3]
On the other hand, you cannot require contributors to implement something
they don't care about nor have required hardware/etc for. Thus, let's use
the approach already in place for porting to architectures:
1. no regressions (enforced by testing migration process)
2. porter patches are privileged:
# devref §5.10.2.2. source NMUs for porters
#
# [...] It also varies whether the architecture is a candidate for
# inclusion into the next stable release [...]
#
# If you are a porter doing an NMU for "unstable", the above guidelines
# for porting should be followed, with two variations. Firstly, the
# acceptable waiting period — the time between when the bug is submitted
# to the BTS and when it is OK to do an NMU — is seven days for porters
# working on the "unstable" distribution. This period can be shortened
# if the problem is critical and imposes hardship on the porting effort,
# at the discretion of the porter group.
I propose to extend these rules to more technologies, starting with init/rc
systems. This will give us an actionable guidance Bdale and Russ requested.
Thus: Guillem, would you consider amending your proposal to:
* extend the above rules to a list of technologies, with the list's initial
contents being:
• sysv-rc, at severity equivalent to a release arch
• openrc, at severity equivalent to a -ports arch
• non-yet-packaged new rc systems, equivalent to an out-of-archive arch
(sysv-rc and openrc share most of the efforts)
Alternatively, you can say just "init scripts" without going into details.
* request a list of non-systemd-hostile policies to be changed[4], initial
contents being:
• an unrelated package forcing an init switch on a straightforward apt
invocation is RC-buggy (usually caused by an unthoughtful deps ordering)
• requesting a redundant .service file when an init script exists, without
a good reason (doubles work and reduces test coverage)
• allowing unrelated packages to be unbuildable when a specific daemon/etc
is installed (ie, should B-Dep/library-Dep on not-yet-existing
systemd-dev instead of systemd, but the problem is not restricted to
systemd)
(Some more terse wording would be nice.)
Meow!
[1]. Such as, it doesn't boot on my new main desktop. Or, it breaks schemes
that rely on mount --bind (which it randomly sometimes converts to --rbind
after a raceable delay, sometimes it doesn't). Or, it not only refuses to
mount degraded btrfs RAID but even unmounts if mounted manually. Or,
sometimes causes data loss of mails sent from cronjobs/exiting daemons.
My list is short only because for obvious reasons I avoid prolonged
exposure to systemd.
[2]. The worst case being patches for compiling policykit both for systemd
and consolekit (initially) then elogind (later), despite a tested
solution being proposed and available since Jan 2018. This led to
Buster being mostly unusable with a modern GUI. Reactions we met with
were: 1. stonewalling (no one but smcv graced us with a response), then
2. stalling (long delays when responding to bugs), and 3. last-minute
demand of large-scale rewrite (a request to make libelogind0
ABI-compatible and replacing libsystemd0, instead of both being
coinstallable).
[3]:
* dependencies on "systemd | other" rather than "other | systemd"; this is
a no-op on a systemd system (installed by debootstrap before any
non-base packages) but causes apt to force an init+rc switch elsewhere
* changing "service" (the rc-agnostic wrapper) to "systemctl"
* (dubious due to my lack of knowledge): the switch from dbus-x11 to
dbus-user-system; the former is not only rc-agnostic but also allows
multiple same-user GUI logins (I have not personally seen a GUI system
with multiple users this millenium, while I remotely log in to my home
box a lot, sometimes needing something GUIish).
* recently added lintian warning requiring maintainers to add a redundant
.service file even if an init script it already there. It doubles the
work and makes one of methods not maintainer-tested (some folks won't
test init scripts, I won't test .service). And in most cases doesn't
even bring any good.
[4]. Avoiding these would be a good way to go also for other proposals that
are not systemd only, too.
--
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄⠀⠀⠀⠀ etc), let the drink age at least 3-6 months.
Reply to: