Debian To Seek A General Resolution Over Their Init System Policy

[ThanosApostolou]

Reading the comments (those who are relevant to the topic), I guess we can all agree that maintaining just the packages for other init systems (like openrc) is not a big deal, but the real effort is maintaining all the init scripts for the packages that need them. The early adaptions of systemd didn't have systemd service files for all packages but they have an automatic procedure to translate the old init scripts to fake systemd services. For example in Debian this is still done for minidlna, which is using an old init script which gets detected by systemd and creates a systemd service (I'm using it on raspberrypi and it's a bit buggy since systemd overrides don't always work, but it's functional).

So, I am wondering maybe it's time for someone to implement the exact opposite, since systemd is now the standard norm. Like a daemon which reads systemd files and translates them to simple init scripts, of course by ignoring the extra functionality that systemd has (like dependencies or whatever) and be easily override-able so that distros can easily fix them when the automation isn't perfect. I personally like very much systemd, but has anyone think about this?

[starshipeleven]

Didn't they destroy all their build infrastructure because of a silly Aprils fools day joke?

No one should trust a distro with that level of incompetence, imagine if Debian or Fedora did something like that.

lol I didn't know this, but I'd say it's believable for the Devuan project.

[starshipeleven]

Reading the comments (those who are relevant to the topic), I guess we can all agree that maintaining just the packages for other init systems (like openrc) is not a big deal, but the real effort is maintaining all the init scripts for the packages that need them. The early adaptions of systemd didn't have systemd service files for all packages but they have an automatic procedure to translate the old init scripts to fake systemd services. For example in Debian this is still done for minidlna, which is using an old init script which gets detected by systemd and creates a systemd service (I'm using it on raspberrypi and it's a bit buggy since systemd overrides don't always work, but it's functional).

So, I am wondering maybe it's time for someone to implement the exact opposite, since systemd is now the standard norm. Like a daemon which reads systemd files and translates them to simple init scripts, of course by ignoring the extra functionality that systemd has (like dependencies or whatever) and be easily override-able so that distros can easily fix them when the automation isn't perfect. I personally like very much systemd, but has anyone think about this?

Afaik the script-to-unit "conversion" is done on the fly by systemd itself when it finds scripts in the usual locations.

Systemd configuration is pretty much all text files with an easy and static syntax (as they are supposed to be easy to write and easy to parse for a machine).

So yes, nothing stops making a shell script to do the conversion (best if on package install, you don't need to do this on boot every time) and either fall back to sane defaults if it can't convert some systemd-only functionality or convert what it can to "the old way" like socket-based service activation that in a classic system should be done through inetd or xinetd or something similar.

And if you are using a decent and modern init like OpenRC that is able to deal with more advanced functionality.

The only thing that keeps this from happening is that most of the serious people that dislike systemd are actually using other distros where this isn't a problem.

But yeah, this should be the ONLY way forward for projects like Devuan in case their parent distro stops requiring SysV init support in their packages, or drops init scripts alltogether.

[skeevy420]

lol I didn't know this, but I'd say it's believable for the Devuan project.

The "joke" was the Devuan team pretended they were hacked and then pretended to act like their packages were vulnerable and then ended up posting:

Dear D1rs,

we have analysed in depth the attack from the "Green Hat Hackers" that
compromised the Devuan infrastructure in the last hours, and we
concluded that you all are:

***** APRIL FOOLS *****

:P

Jokes like if Arch posted an "Arch Linux by Microsoft" banner or if they swapped the primary link to Arch Wiki to go the Manjaro Wiki (it sucks) are funny; Repacing the Suse Gecko with the Geico Gecko would be funny. Pretending that you've been hacked and that the repositories could contain malicious code makes them look incompetent and like assholes when the "joke" is revealed.

[andyprough]

The April Fools joke was a home page message that said. "WE TURNED ALL DEVUAN'S SHITTY WEBSITES INTO PROPER GOPHERHOLES". Anyone who couldn't see through that, especially on April 1, but really on any day, was born without any sense of humor or discernment.

[F.Ultra]

That is exactly what I mean: If your package has to "support" some particular init software, that is a sign of poor design decisions. If your executable requires some additional script to be started - that is bad enough already - but if that script then also has to take into consideration particularities of software A or B calling exec() on it - that is even worse.

So in your perfect world the end users each have to create their own init scripts for all the daemons that they want to run at boot? What exactly is it that you think that maintainers do?

[Karl Napf]

The April Fools joke was a home page message that said. "WE TURNED ALL DEVUAN'S SHITTY WEBSITES INTO PROPER GOPHERHOLES". Anyone who couldn't see through that, especially on April 1, but really on any day, was born without any sense of humor or discernment.

You mean like the admins of the devuan.org website? They disconnected the build servers from the compromised site and crippled Devuan's ability to build packages for month.

You mean that harmless joke that cost Devuan one of its core contributors and very nearly a second?

LWN has a write-up of the incident: https://lwn.net/Articles/786593/

[skeevy420]

The April Fools joke was a home page message that said. "WE TURNED ALL DEVUAN'S SHITTY WEBSITES INTO PROPER GOPHERHOLES". Anyone who couldn't see through that, especially on April 1, but really on any day, was born without any sense of humor or discernment.

If it would have been just that, pretending the site was hacked, label it under "funny" and call it a day. The maintainers spreading FUD about how the packages and repositories might be compromised is where it went from funny to "OMFG, my system is compromised; WTF do I do" unfunny. Pretending the site is hacked is one thing, pretending the repositories are compromised isn't funny.

Regardless of ones' distribution of choice, there's an inherent level of trust we have to have with those who maintain our distributions. When those we have to trust joke about things we have no choice but to trust them with, they lose that credibility and trust regardless if they're a Linux distribution maintainer "joking" about a security breach, a police officer "joking" about finding your mom stabbed 43 times, your doctor "joking" about how you're now HIV positive; doesn't matter who they are or what they do, cross a certain line and you lose that inherent credibility and trust.

[andyprough]

You are completely mischaracterizing the timeline of events described in that LWN article. The downtime was not in any way a direct result of the prank. It was due to a later reboot of an already misbehaving build server that decided not to come back up.

[CommunityMember]

they won't be able to maintain init scripts for all Debian packages themselves.

Depending on your installation, there are only a few hundred services with init scripts to manage, and those files are *mostly* static, so repackaging those services would probably be sustainable if someone decided to create an appropriate way to repackage and rebuild for those known packages if/when those services only ship systemd unit files. The real issue is likely the other dependencies on systemd (only) that will continue to be added over time to packages, resulting in an ever increasing effort by the devuans to maintain their stated goal. As long as the devuans faith is strong enough, they will find a way.