On Fri, Oct 24, 2014 at 05:40:28AM -0700, Josh Triplett wrote: > Ansgar Burchardt wrote:
My apologies, that should have been: > Aigars Mahinovs wrote: (The web archives on lists.debian.org have reply-to links, but those links don't include quoted mail text as the BTS links do; I copy-pasted the wrong name when constructing the attribution.) > > 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/20141024124252.GA16760@thin
