Ansgar Burchardt wrote: > The root of the problem is coming from upstream not caring about > alternative init systems. To take the logind case as an example - each > of the dependencies from GDM to systemd make perfect sense in > isolation. However, the end result (was) that GDM only worked with > systemd almost by accident. No developer in that chain was compelled > to run this under other init systems.
We have not, historically, banned packages from introducing dependencies on specific (FOSS) software they use, particularly in the absence of patches implementing alternative dependencies. Imagine if we said "The root of the problem is coming from upstream not caring about alternative libc implementations.", and started complaining at packages that won't build with newlib? Sure, many people have very legitimate reasons to want to run some packages with a smaller libc implementation; however, the burden remains firmly on them to make that work, and the project cannot force maintainers of arbitrary packages to care about non-glibc. We have a substantial number of packages in Debian that depend specifically on a Linux kernel, or even on specific architectures. While there are people working to port those packages to alternative kernels such as the Hurd and *BSD, I don't see anyone calling for a GR to force packages to support alternative kernels; instead, I see the people who care about running those kernels actually doing an impressive amount of work to write patches. Similarly, even for packages that do code generation (such as compiled programming languages), and thus only support specific architectures, people have actually done the substantial amount of work to add additional architecture support. What makes the systemd case so drastically different that those who care about alternative init systems cannot follow the same procedure? > However these choices heavily impact our users who (for whatever > reasons) want or need to use another init system. Such users are used > to having to write an odd init script for some service - that is an > acceptable extra work for using a non-default init system. However it > is a much harder task to have to implement a new API introduced by > systemd or creating something like systemd-shim. We should not be > pushing such burdens to our users. That is too hard a punishment for > using an alternative init system and also upstream (or maintainer) are > far better positioned to implement some workaround to make the > software work with alternative inits. Upstream and the maintainer don't necessarily *care*. A GR will not make them care. As a user, if you want something that does not exist, you file a wishlist bug and you hope to find someone willing to implement it for you, or you work to convince people to care. (And to provide a bit of contrast here, several upstreams are making a substantial effort to continue supporting alternate init systems even when not doing so would be far easier and more fun. The near-complete absence of any real examples in Debian of packages that currently *don't* support sysvinit or that refuse to accept patches makes the arguments surrounding this issue ring rather hollow.) - Josh Triplett -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141024124026.GA16686@thin
