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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
