Debian votes on init systems

Posted Dec 19, 2019 0:03 UTC (Thu) by qtplatypus (subscriber, #132339)
In reply to: Debian votes on init systems by mathstuf
Parent article: Debian votes on init systems

I think it would be fairer to say “Their use cases meant that these where not problems for them”. Which argues for init diversity, if you have a use case where systemd just doesn’t anything for you, you should be able to use an alternative init with minimal friction.

Debian votes on init systems

Posted Dec 19, 2019 0:32 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (8 responses)

So, if you have a use case that doesn't require glibc, you should be able to use an alternative libc with minimal friction?

Debian votes on init systems

Posted Dec 19, 2019 12:08 UTC (Thu) by qtplatypus (subscriber, #132339) [Link]

I think I’m a broad sense if it is practical to do so it is desirable. Though I personally don’t think that the init system and the standard C library are equivalent.

Debian votes on init systems

Posted Dec 19, 2019 14:19 UTC (Thu) by smurf (subscriber, #17840) [Link] (6 responses)

Actually, yes. For example, people have been mostly-porting Debian to musl libc. I'd expect the patches required for this to be accepted by Debian maintainers just like patches for non-systemd init systems, or like patches for compiling with clang instead of gcc. That's not the problem.

The problem is, just like in the non-systemd case, what should happen if Upstream doesn't accept these patches. Should the Debian maintainer be expected to carry them? Indefinitely? What if the patch doesn't apply to a new version of the code in question – is the maintainer required to forward-port the patch? If they can't or won't do that and the package no longer works, is that an RC bug? and so on and so forth.

Debian votes on init systems

Posted Dec 19, 2019 14:32 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (3 responses)

Another option is what I did when a similar thing that happened when upstreams for packages I maintained in Fedora refused to port to Python3: drop them from the distro. If they're important enough that those packages cause worry with that kind of response, then I guess you'll have to find a new upstream (in one way or another). This GR is about whether those patches to support alternate init systems is an RC bug or not (not supporting Python3 obviously is, init systems…well, that's what this vote is about, libc? even lower priority I would think).

Debian votes on init systems

Posted Dec 19, 2019 15:19 UTC (Thu) by Zolko (guest, #99166) [Link] (2 responses)

"drop them from the distro"

I think this is the correct approach: Debian making the biggest part of the Linux ecosystem (if you include Ubuntu, Mint...) then a package that is rejected from Debian because of lack of init diversity would rapidly sink into irrelevance, and be replaced by a fork that does support init diversity.

I think that the Debian maintainers don't realize the power they hold over package maintainers. And I think that Red-Hat (IBM now !) realize this also, and systemd is the Trojan horse to take control of the Linux world. Put this in perspective with the Richard Stallman eviction of the FSF: we're witnessing a power-grab of the open-source movement against the free-software brigade.

Debian votes on init systems

Posted Dec 19, 2019 15:28 UTC (Thu) by pizza (subscriber, #46) [Link]

> I think this is the correct approach: Debian making the biggest part of the Linux ecosystem (if you include Ubuntu, Mint...) then a package that is rejected from Debian because of lack of init diversity would rapidly sink into irrelevance, and be replaced by a fork that does support init diversity.

You vastly, vastly overstate the importance of Debian packages, especially with respect to the likes of Ubuntu.

(At this point, the number of users running "Debian-derived" distros without systemd as pid1 are a rounding error on the overall userbase)

At the end of the day, a distro that doesn't meet its users needs will fade into irrelevance; and advocating for a policy that excludes software that meets every definition of the DFSG only does a disservice to its users.

> Put this in perspective with the Richard Stallman eviction of the FSF: we're witnessing a power-grab of the open-source movement against the free-software brigade.

Huh? systemd is GPLv2-licensed Free Software.

Debian votes on init systems

Posted Dec 20, 2019 1:11 UTC (Fri) by flussence (guest, #85566) [Link]

> I think that the Debian maintainers don't realize the power they hold over package maintainers. And I think that Red-Hat (IBM now !) realize this also, and systemd is the Trojan horse to take control of the Linux world. Put this in perspective with the Richard Stallman eviction of the FSF: we're witnessing a power-grab of the open-source movement against the free-software brigade.

I think you need a reality check. FOSS is functionally a “meritocracy”; I'm sure you've heard that word plenty of times, as do-nothing hecklers on imageboards seem to love bandying it around as if it somehow elevates them to the status of royalty. What it actually means is those who *do the work* get to make the rules. And they (the people actually doing the work, funding the work, writing the code) have ruled that you as a guest on their property will use systemd, as it means less work for them. Don't like it? Patches welcome.

Debian votes on init systems

Posted Dec 19, 2019 18:21 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

If including the musl patch imposes any additional maintenance burden on the packager, then while musl isn't an official Debian port there's no absolute expectation that the maintainer would accept it - policy certainly doesn't require that they do. I'd expect many to be happy to carry small patches to make this easier, but it's not an obligation. For packages that actually rely on functionality that's in glibc but not elsewhere, things become more complicated. And, outside the current policy obligations, it's the same for non-systemd init support - in most cases there's a relatively small overhead caused by looking after it, but in other cases it's much more significant. Creating an expectation that core system components should be entirely replaceable is creating an expectation that package maintainers will take on additional work without benefiting the overwhelming majority of users.

Debian votes on init systems

Posted Dec 19, 2019 19:30 UTC (Thu) by mpr22 (subscriber, #60784) [Link]

I would not, in the general case, expect Debian package maintainers to accept and carry patches for musl support, any more than I would expect the upstream developers to do so.

This is because in the general case, the level of change required for musl support can range from "trivial one-line change" to "vendoring random chunks of glibc because critical non-optional functionality depends on glibc features that musl doesn't provide and have displayed unfriendliness towards the notion of being asked to provide".