Debian network-manager: Please restore removed init script

Post by zentiggr » Wed, Sep 16, 2020, 3:19 PM UTC

jwilk wrote: post #26

tremon wrote: post #8

Earlier quoted context omitted.

I haven't followed Debian in recent years, but I thought the technical committee had said that maintainers were not to remove working sysvinit support nor refuse patches for it, unless the package itself was clearly tied to the specific init system?

https://bugs.debian.org/746715 > For the record, the TC expects maintainers to continue to support the multiple available init systems in Debian. That includes merging reasonable contributions, and not reverting existing support without a compelling reason.

Post by tremon » Wed, Sep 16, 2020, 3:32 PM UTC

pabs3 wrote: post #25

dijit wrote: post #21

FWIW Network-manager depends on dbus, and dbus hard depends on systemd for some years now.

> dbus hard depends on systemd That doesn't seem to be the case, the dbus package only depends on libsystemd0 and installing dbus in a clean chroot doesn't pull in systemd. $ apt-cache show dbus | grep Depends | grep -o ...systemd. | sort -u libsystemd0

  $ aptitude why network-manager systemd
  p   network-manager Depends libpam-systemd
  i   libpam-systemd  Depends systemd (= 229-4ubuntu21.29)

  $ aptitude why dbus systemd
  i   dbus            Depends    adduser
  i   adduser         Depends    debconf | debconf-2.0
  i   debconf         Recommends apt-utils (>= 0.5.1)
  i   apt-utils       Depends    apt (= 1.2.32ubuntu0.1)
  i   apt             Depends    gnupg | gnupg2
  i   gnupg2          Depends    gnupg-agent (= 2.1.11-6ubuntu2.1)
  i   gnupg-agent     Depends    pinentry-curses | pinentry
  p   pinentry-gnome3 Provides   pinentry
  p   pinentry-gnome3 Depends    libgtk-3-0 (>= 3.0.0)
  p   libgtk-3-0      Depends    libcolord2 (>= 0.1.10)
  p   libcolord2      Recommends colord
  p   colord          Depends    policykit-1 (>= 0.103)
  i   policykit-1     Depends    libpam-systemd
  i   libpam-systemd  Depends    systemd (= 229-4ubuntu21.29)

Post by m4r35n357 » Wed, Sep 16, 2020, 3:45 PM UTC

Oomoo0sh wrote: post #5

m4r35n357 wrote: post #4

Biebl sounds like a dick.

Or someone long past burnout. In any case, that attitude will only cause more problems.

Post by giancarlostoro » Wed, Sep 16, 2020, 4:06 PM UTC

grifferz wrote: post #12

giancarlostoro wrote: post #6

Earlier quoted context omitted.

What's sad is this is the kind of thing that makes Debian unstable in my eyes. Being able to choose whatever init system you want on your Linux distro is something that should just be a thing. Additionally I'm confused are these packages not pulled from another source or is Debian the sole developer of this one? I would expect support for other init systems to be in parity with the parent project of the package in qu…

> is Debian the sole developer of this one? The init script is specific to Debian. I don't know what network-manager's stance is on init system support or even if they have one. I wasn't able to find one in a quick search.

Post by rleigh » Wed, Sep 16, 2020, 4:30 PM UTC

pabs3 wrote: post #27

phone8675309 wrote: post #9

I can understand the maintainer saying that they need people to test it because they run systemd and therefore don't have a system running another init system to test on. I can't understand removing working support. Maybe split the SysV support into another package that is maintained by someone who is able and willing to spend the time testing it under other init systems.

It is fairly trivial to test other init systems using virtual machines, booting off another installation on USB or even by installing the other init system and rebooting. Also, delegating the testing to those using sysvinit and NM would have been just fine too.