On Fri, 21 Feb 2014 09:50:24 -0500 Tanstaafl <tansta...@libertytrek.org> wrote:
> All myself and others have been insisting on is that systemd > proponents be prevented from unilaterally creating some kind of > dependenc[y][ies] whereby, through that backdoor, they create a > situation where the *current* *default* init system must be switched. It are the consumers that do, sometimes even the packagers; because some neat future that fits them is provided by one implementation, they adopt that and given limited manpower they expect other implementations to follow. This is whilst stating "However, long term hopefully gnome-session can die and such code in systemd." in the following blog post by a GNOME foundation as well as GNOME release team member: https://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logindsystemd-thoughts/ On Gentoo, we indeed prevent such dependencies where manpower allows us; for example, to give an opposite example, we've even removed sys-apps/openrc from several package dependencies to allow for its removal. The same is actively guarded for sys-apps/systemd; but for both, you'll be able to find an exception to it here or there. The same is said by one of the Gentoo Council members in a comment on another blog post here, worth reading: https://blogs.gnome.org/ovitters/2014/02/03/my-thoughts-on-the-default-init-system-for-debian-discussion/comment-page-1/#comment-782 > And your preference for systemd doesn't obligate your distro of > choice to change to it as the *default* init system. What is a default in a distro with meta choices anyway? Yes, choice: https://bugs.gentoo.org/show_bug.cgi?id=482702 > Again, we are just insisting that systemd proponents be prevented > from forcing gentoo into a situation where we are *forced* to switch > to systemd for the *default* init system. While it is something to worry about; however, it's only happened once and temporarily for GNOME (decided on by our maintainers), this has no implication that this will happen much more beyond that. There are people that are going to actively prevent that if it does happen. > > Hence the general case above. If you want to use foo without using > > bar, but the upstream and package maintainers of foo want to use > > bar, then it's _your_ responsibility to make foo work without bar. > > PERIOD. > > I agree... so, if *you* want to use systemd, it is *your* > reponsibility to make systemd work without impacting existing gentoo > users The impact, if any, is kept as minimal as possible; Gentoo, as stated by it philosophy, about page and documentation is a meta distribution which implies we attempt to support choices. Sometimes this means that minimal adjustments need to be made to support multiple choices. > *or* the fact that gentoo has selected OpenRC as it's default init > system. It's rather a consequence than a fact; for it to be a fact, there needs to be an accepted motion from an higher instance stating it to be so. > This isn't about individual packages. It is about one of the choices > that *Distro's* must make - in this case, regarding something very > significant (the choice of what to use as the default init system). Both (separate stage3's), or none at all (stage<3); are also options. :) > We, again, are simply insisting that it is the responsibility of the > developers of systemd to *not* create situations where they *force* > other distro's into *impossible* *situations* where they are *forced* > to switch their init systems or have basic system packages stop > working. It are the consumers, to some extent even the packagers, that do this. > The best way for gentoo, as a distro, to protect its users and it's > ecosystem, is to provide a sane, managed approach for systemd > proponents to get systemd added to gentoo as a formally supported > *optional* init system. +1 > Then, and only then, can it be judged on its *merits*, +1 > and then and *only* then should it (imnsho) ever be considered as a > potential candidate for being made a new *default*. -1; unless, well, it has lost its "controversial" status in the future. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
