5 ms·

I tried to run sysvinit on Debian for a long time. What happened was that often when I tried to install something, I got systemd back, and sysvinit thrown out,

by dirkt 9y ago

I tried to run sysvinit on Debian for a long time. What happened was that often when I tried to install something, I got systemd back, and sysvinit thrown out, via some funny dependencies. Maybe I was doing something wrong. Maybe you just didn't want to install the packages I wanted to install. I don't know. In any case, the pain was real. So finally I switched to Devuan, even though I wanted to stay with Debian, and now those problems and the time I had to spend fighting them are gone. That's why Devuan exists. YMMV, of course.

tomatocracy 9y ago
I run Debian with sysv too and had the same issue early on. Fortunately, that one is easily fixed - if you drop the following into a file in /etc/apt/preferences.d, it will stop that from happening: Package: systemd Pin: release o=Debian Pin-Priority: -1 Package: systemd-sysv Pin: release o=Debian Pin-Priority: -1 Package: systemd:i386 Pin: release o=Debian Pin-Priority: -1 Package: systemd-sysv:i386 Pin: release o=Debian Pin-Priority: -1 The i386 parts are only needed if you have it setup with multi-architecture. Unfortunately, I have also had to recompile some packages to remove systemd dependencies as well. Fortunately that hasn't been too much effort so far but eventually I may have to switch to Devuan. The most ridiculous one was policykit and neatly illustrates the creeping "infection" of systemd into Debian - policykit-1 hard-depends on libpam-systemd which hard-depends on systemd. Why neither was marked as "Recommends" instead of "Depends" I can't understand (policykit-1 -> libpam-systemd or libpam-systemd -> systemd) - either would have been fine and allowed both options to work perfectly well as far as I can tell.
- justinclift 9y ago
  > Why neither was marked as "Recommends" instead of "Depends" I can't understand (policykit-1 -> libpam-systemd or libpam-systemd -> systemd) Sounds like a bug report is needed, so that gets fixed. :)
  - kasabali 9y ago
    No it is not needed because it has already been filled and "wontfix"ed years ago. "Fill a bug report" automatic reply gets old quickly and it's especially absurd when it's said by a person totally uninformed on the issue.
- dirkt 9y ago
  > Unfortunately, I have also had to recompile some packages to remove systemd dependencies as well. And I think that's exactly what Devuan does - they recompiled/rebuild the packages with funny dependencies that caused systemd to creep back in. The rest are just the normal Debian packages. They even forward you to the Debian download servers for those. The advantage of using Devuan is that they have spent tome to do this work, once, so now not everyone who wants to use Debian without systemd has to spent all this work again. Yes, the Debian devs could have easily done this themselves. For some reason they decided not to.
agwa 9y ago
With the correct pin (as described in my linked comment), you can prevent systemd-as-PID1 from coming back. If you install certain desktop packages, then a package named "systemd" might come back, but systemd won't actually run as PID 1. Since the pain from systemd comes from it running as PID 1, I don't see a problem with this. If you want a system that's 100% free of all systemd code, even if it's not doing anything, then you need Devuan, but personally I don't see that as a compelling reason to fork Debian.
- dvfjsdhgfv 9y ago
  > With the correct pin (as described in my linked comment), you can prevent systemd-as-PID1 from coming back. Frankly, it's an ugly hack, not a proper solution. I hope to run my servers for years to come and the upgrade process should be as smooth as it can be.

by dirkt 9y ago

tomatocracy 9y ago

I run Debian with sysv too and had the same issue early on. Fortunately, that one is easily fixed - if you drop the following into a file in /etc/apt/preferences.d, it will stop that from happening: Package: systemd Pin: release o=Debian Pin-Priority: -1 Package: systemd-sysv Pin: release o=Debian Pin-Priority: -1 Package: systemd:i386 Pin: release o=Debian Pin-Priority: -1 Package: systemd-sysv:i386 Pin: release o=Debian Pin-Priority: -1 The i386 parts are only needed if you have it setup with multi-architecture. Unfortunately, I have also had to recompile some packages to remove systemd dependencies as well. Fortunately that hasn't been too much effort so far but eventually I may have to switch to Devuan. The most ridiculous one was policykit and neatly illustrates the creeping "infection" of systemd into Debian - policykit-1 hard-depends on libpam-systemd which hard-depends on systemd. Why neither was marked as "Recommends" instead of "Depends" I can't understand (policykit-1 -> libpam-systemd or libpam-systemd -> systemd) - either would have been fine and allowed both options to work perfectly well as far as I can tell.

justinclift 9y ago
> Why neither was marked as "Recommends" instead of "Depends" I can't understand (policykit-1 -> libpam-systemd or libpam-systemd -> systemd) Sounds like a bug report is needed, so that gets fixed. :)
- kasabali 9y ago
  No it is not needed because it has already been filled and "wontfix"ed years ago. "Fill a bug report" automatic reply gets old quickly and it's especially absurd when it's said by a person totally uninformed on the issue.
dirkt 9y ago
> Unfortunately, I have also had to recompile some packages to remove systemd dependencies as well. And I think that's exactly what Devuan does - they recompiled/rebuild the packages with funny dependencies that caused systemd to creep back in. The rest are just the normal Debian packages. They even forward you to the Debian download servers for those. The advantage of using Devuan is that they have spent tome to do this work, once, so now not everyone who wants to use Debian without systemd has to spent all this work again. Yes, the Debian devs could have easily done this themselves. For some reason they decided not to.

agwa 9y ago

With the correct pin (as described in my linked comment), you can prevent systemd-as-PID1 from coming back. If you install certain desktop packages, then a package named "systemd" might come back, but systemd won't actually run as PID 1. Since the pain from systemd comes from it running as PID 1, I don't see a problem with this. If you want a system that's 100% free of all systemd code, even if it's not doing anything, then you need Devuan, but personally I don't see that as a compelling reason to fork Debian.

dvfjsdhgfv 9y ago
> With the correct pin (as described in my linked comment), you can prevent systemd-as-PID1 from coming back. Frankly, it's an ugly hack, not a proper solution. I hope to run my servers for years to come and the upgrade process should be as smooth as it can be.