Bug#762116: general: Some packages depend on a particular init system
Package: general
Severity: normal
Dear Maintainer,
This bug applies to many desktop applications, and runs counter to Debian's
goals of supporting multiple init systems. I classified this bug as
normal, but I think consideration should be given to classifying it as
serious.
An example:
'apt-get --no-install-recommends install brasero'
gives me:
The following extra packages will be installed:
gvfs gvfs-daemons gvfs-libs libpam-systemd libudisks2-0 systemd systemd-sysv
udisks2
Suggested packages:
vcdimager libdvdcss2 tracker gvfs-backends systemd-ui reiserfsprogs
exfat-utils mdadm
Recommended packages:
policykit-1-gnome policykit-1
The following packages will be REMOVED:
sysvinit-core
The following NEW packages will be installed:
brasero gvfs gvfs-daemons gvfs-libs libpam-systemd libudisks2-0 systemd
systemd-sysv udisks2
0 upgraded, 9 newly installed, 1 to remove and 0 not upgraded.
Need to get 0 B/3,413 kB of archives.
After this operation, 11.0 MB of additional disk space will be used.
So installing a cd-burning application triggers a change of my init system.
I know about systemd-shim, and I'll talk about that in a minute.
As I understand it, brasero uses gvfs as its method of detecting removable
media. gvfs depends on gvfs-daemons, which depends on udisks2, which
depends on libpam-systemd, which depends on systemd-sysv.
Each of those dependencies may be valid (I really don't know). The end
result, though, is somewhat nonsensical. A cd-burning application
depends on a particular init system -- even though that init system does not
contain any functionality that the cd-burning application cannot do without.
I suspect the culprit here is packages which perform a broad array of
functions, rather than doing one thing and doing it well. So brasero needs
X functionality, which can be found in package W. Package W also provides
Y functionality, which depends on systemd-sysv. So therefore brasero depends
on systemd-sysv, even though it doesn't *need* it.
This kind of entanglement is going to make it very hard for Debian to
sincerely support multiple init systems.
Since I know there is a thing called systemd-shim (no thanks to apt, in
this case), I can install systemd-shim prior to the apt-get command shown
above, and then my init system will not be changed on me. But is
systemd-shim really the solution we need to the problem above? I certainly
appreciate the developers' work, but it seems that the problem systemd-shim
solves could be better addressed a little closer to the root. And the root,
I think, is single packages which provide multiple (and possibly unrelated)
functionality. Without fixing the root of the problem, Debian's goal of
supporting multiple init systems depends entirely on the success of the
systemd-shim team.
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Reply to: