5 ms·

I never understood why the Devuan developers could not just contribute their work to Debian directly. Yes, systemd had become the default init system, but the i

I never understood why the Devuan developers could not just contribute their work to Debian directly. Yes, systemd had become the default init system, but the idea that other developers would oppose contributions that would do nothing but improve interoperability is just absurd. To me, this whole "we're forking Debian" thing just feels like a strongly emotional opposition to systemd, not rational solution to the init system problem.

hd4 9y ago
Yes it would have made better sense to create some kind of process to switch mainline Debian from systemd to runit, openrc etc.
bkor 9y ago
Debian can already run various init systems. E.g. you can run GNOME under sysvinit. Within Devuan they just removed GNOME. If you want init system choice, run Debian (or e.g. Gentoo). Devuan seems more about hating systemd than any actual choice.
- nottorp 9y ago
  As far as i know, systemd is creeping in as a dependency of a lot of unrelated packages - even UI packages. So you can have a Debian that doesn't run systemd, perhaps, but not a Debian that doesn't depend on bits of pieces of the systemd OS any more.
  - bkor 9y ago
    You have a tiny systemd library which does little more than checking if systemd is running. It's a helper library for doing that check. Within Devuan they didn't want this dependency, but that's unrelated from being able to use software under another init system. There's a huge difference between not accepting any dependency with systemd in the name vs being able to use another init system. That some software has a dependency does NOT mean that the software is restricted to only run under systemd.
    - frodob12 9y ago
      But these are hard deps not just recommends so will pull in systemd dependencies regardless of it using them or not. If it were a recomends type dep, again no one would have a problem. It used to be considered bad packaging to hard dep when recommends or suggests would suffice. 7.2 states: "When selecting which level of dependency to use you should consider how important the depended-on package is to the functionality of the one declaring the dependency" You say "being able to use software under another init system." Looks like the level of dependency should be adjusted to fit your point.
      - blubb2k 9y ago
        You might want to learn how shared libraries work under Linux. Then you might be able to understand why packages have a Depends: libsystemd0 (which btw. doesn't depend on systemd itself).
    - appleflaxen 9y ago
      the entire point of devuan (iiuc) is to have a clean separation of function. if systemd is a wide dependency, then the separation of the init system is a bit superficial and isn't what the distro cares about.
lamby 9y ago
One possible reason: They are making a philosophical stand/statement against systemd.
- frodob12 9y ago
  Another is that they can see where the systemd bus is going and it's not somewhere they choose to follow.
vacri 9y ago
Systemd is a lot more than just init. It also manages user auth, udev, time, syslog, and a few other things.
- frodob12 9y ago
  That is the main complaint.
  - vacri 9y ago
    My point is more that systemd makes less sense if you think of it as just init. "Why does init need to manage -foo-?" is a valid question. But "Why does a general 'system daemon' need to manage -foo-?" tends to be self-answering.
frodob12 9y ago
They were told to by debian. They argued for as long as they could while debian was still 'their' distribution to change the direction systemd would take it. It was clean that wasn't going to happen. Final response; "If you don't like it you can always fork. But you'll never release anything." So now they have forked and they have released. So now their splitters. Cake and eat it types, what can you do?
- ckastner 9y ago
  > They were told to by debian. I don't follow. Are you saying that representatives of the Debian project refused to collaborate with the Devuan developers with regards to improving init system interoperability?
  - deleted 9y ago
    [deleted]
  - parent5446 9y ago
    I mean, I think the comment was pretty clear, and that sounds like exactly what they said.
    - blubb2k 9y ago
      What did "Debian" say exactly? Can you link it? Or are you just stating what you imagine "they" might have said? :)
      - parent5446 9y ago
        I'm just saying I think that's what the parent comment is saying. As for whether Debian actually said that...well that's anybody's guess.
      - AdieuToLogic 9y ago
        This[0] PCWorld article quotes two Debian list email posts which may clarify what "Debian" said. From one of the email[1]: So, this vote effectively gives systemd the win And the other[2] shows the result of Debian voting on the topic. 0 - http://www.pcworld.com/article/2854717/meet-devuan-the-debian-fork-born-from-a-bitter-systemd-revolt.html http://www.pcworld.com/article/2854717/meet-devuan-the-debia... 1 - https://lists.debian.org/debian-ctte/2014/02/msg00338.html https://lists.debian.org/debian-ctte/2014/02/msg00338.html 2 - https://vote.debian.org/~secretary/gr_initcoupling/results.txt https://vote.debian.org/~secretary/gr_initcoupling/results.t...

hd4 9y ago

Yes it would have made better sense to create some kind of process to switch mainline Debian from systemd to runit, openrc etc.

bkor 9y ago

Debian can already run various init systems. E.g. you can run GNOME under sysvinit. Within Devuan they just removed GNOME. If you want init system choice, run Debian (or e.g. Gentoo). Devuan seems more about hating systemd than any actual choice.

nottorp 9y ago
As far as i know, systemd is creeping in as a dependency of a lot of unrelated packages - even UI packages. So you can have a Debian that doesn't run systemd, perhaps, but not a Debian that doesn't depend on bits of pieces of the systemd OS any more.
- bkor 9y ago
  You have a tiny systemd library which does little more than checking if systemd is running. It's a helper library for doing that check. Within Devuan they didn't want this dependency, but that's unrelated from being able to use software under another init system. There's a huge difference between not accepting any dependency with systemd in the name vs being able to use another init system. That some software has a dependency does NOT mean that the software is restricted to only run under systemd.
  - frodob12 9y ago
    But these are hard deps not just recommends so will pull in systemd dependencies regardless of it using them or not. If it were a recomends type dep, again no one would have a problem. It used to be considered bad packaging to hard dep when recommends or suggests would suffice. 7.2 states: "When selecting which level of dependency to use you should consider how important the depended-on package is to the functionality of the one declaring the dependency" You say "being able to use software under another init system." Looks like the level of dependency should be adjusted to fit your point.
    - blubb2k 9y ago
      You might want to learn how shared libraries work under Linux. Then you might be able to understand why packages have a Depends: libsystemd0 (which btw. doesn't depend on systemd itself).
  - appleflaxen 9y ago
    the entire point of devuan (iiuc) is to have a clean separation of function. if systemd is a wide dependency, then the separation of the init system is a bit superficial and isn't what the distro cares about.

lamby 9y ago

One possible reason: They are making a philosophical stand/statement against systemd.

frodob12 9y ago
Another is that they can see where the systemd bus is going and it's not somewhere they choose to follow.

vacri 9y ago

Systemd is a lot more than just init. It also manages user auth, udev, time, syslog, and a few other things.

frodob12 9y ago
That is the main complaint.
- vacri 9y ago
  My point is more that systemd makes less sense if you think of it as just init. "Why does init need to manage -foo-?" is a valid question. But "Why does a general 'system daemon' need to manage -foo-?" tends to be self-answering.

frodob12 9y ago

They were told to by debian. They argued for as long as they could while debian was still 'their' distribution to change the direction systemd would take it. It was clean that wasn't going to happen. Final response; "If you don't like it you can always fork. But you'll never release anything." So now they have forked and they have released. So now their splitters. Cake and eat it types, what can you do?

ckastner 9y ago
> They were told to by debian. I don't follow. Are you saying that representatives of the Debian project refused to collaborate with the Devuan developers with regards to improving init system interoperability?
- deleted 9y ago
  [deleted]
- parent5446 9y ago
  I mean, I think the comment was pretty clear, and that sounds like exactly what they said.
  - blubb2k 9y ago
    What did "Debian" say exactly? Can you link it? Or are you just stating what you imagine "they" might have said? :)
    - parent5446 9y ago
      I'm just saying I think that's what the parent comment is saying. As for whether Debian actually said that...well that's anybody's guess.
    - AdieuToLogic 9y ago
      This[0] PCWorld article quotes two Debian list email posts which may clarify what "Debian" said. From one of the email[1]: So, this vote effectively gives systemd the win And the other[2] shows the result of Debian voting on the topic. 0 - http://www.pcworld.com/article/2854717/meet-devuan-the-debian-fork-born-from-a-bitter-systemd-revolt.html http://www.pcworld.com/article/2854717/meet-devuan-the-debia... 1 - https://lists.debian.org/debian-ctte/2014/02/msg00338.html https://lists.debian.org/debian-ctte/2014/02/msg00338.html 2 - https://vote.debian.org/~secretary/gr_initcoupling/results.txt https://vote.debian.org/~secretary/gr_initcoupling/results.t...