Aigars Mahinovs wrote: > On 24 October 2014 13:33, Ansgar Burchardt <ans...@debian.org> wrote: > > So, if P has a hard dependency on systemd-as-pid1, why do you want to > > take P away from me? Because people not liking systemd are more > > important than people not caring about it or even being okay with it? > > It is not about "people not liking systemd". It is about people using > other init systems. The question is about how strongly do we feel > about supporting this group of users.
"we" don't consistently feel any way in particular about supporting this group of users. People who care can do the work, as always. > > I don't like some software too, but am sometimes required to use it > > without an alternative. Can I demand that I can use packages without > > said software? Like demanding libraries having to provide language > > bindings for at least two languages so I don't have to use PHP[1]? :) > > Init system is special because there can be only one active in the > system. If app1 depends on systemd (as PID 1) and app2 depends on > runit (as PID 1) then it becomes impossible to use both apps (without > changing init system and rebooting). Also IMHO init system should be a > user choice and not dictated by other, unrelated, software. Kernels are special because there can be only one active in the system. If app1 depends on Linux and app2 depends on FreeBSD, then it becomes impossible to use both apps (without changing kernels and rebooting). And yet we don't stop applications from declaring "Architecture: linux-any". And the world has not ended. People who maintain non-Linux kernels have a substantial amount of work to do, and I find it very impressive how much they've gotten working. Yet nobody has proposed a GR forcing support for kFreeBSD or the Hurd; the people working on them have simply *done the work*, and in some cases successfully convinced others to do the same. (And analogously, non-Linux kernels such as FreeBSD often have substantial shim layers providing Linux APIs for the purposes of porting software.) > In any case, this is uncharted territory, because (to my knowledge) > until systemd started integrating system level services into init > system itself, applications never depended on particular APIs of init > systems. Sure they did. Applications depended on daemons which depended specifically on sysvinit functionality: /etc/init.d, /etc/rc?.d, LSB init script metadata, dependencies on specific scripts and their functionality. It wasn't much, but it was something. Consider the burden that placed on other init systems. Consider what would happen if a new init system came along, which did *not* implement the sysvinit interfaces; would we suddenly force applications to stop depending on sysvinit features? Or would we simply say "patches welcome"? In any case, even if this problem were new to init systems, it's not new to many other things: kernels, C libraries, compilers, and many other things. > We need to make a conscious decision on how to handle that. If we > don't then it is likely that the process will go on as before: > * systemd introduces a great new system level service, How dare they build software people want? > * key apps depend on that service to do great things (and stop working > on all other init systems), How dare they take advantage of time-saving common code, or introduce new functionality for which no support previously existed? > * people using other init systems are sad, "How dare other people do work on init systems other than ours?" > * after a lot of hard work a new ugly hack shows up to patch out or > fake out the new service (making apps kind of work again, but not as > good as before), > * another flamewar/GR is started to stop systemd dependencies breaking > software for other people Yeah, sadly, I don't expect this to be the last flamewar on the topic, even after it gets voted down. > * (repeat) Modulo the flamewar/GR, that's the normal, expected, and desirable process. It also has the critically important property of only continuing as long as enough people actually want to do the work, rather than becoming self-perpetuating as a GR-enforced requirement would. > I am sure that there will be several more rounds of these because > systemd has a *lot* of very interesting and useful services coming up > in their plans. I already expect to see several more rounds over *existing* services that the systemd package hasn't yet enabled. For instance, timesyncd, networkd, systemd-nspawn, etc. I anticipate a painfully long delay before I can actually count on those. > I can't wait to use most of them, but at the same time > it sound like they are developed in a tight coupling with systemd > itself thus making all those very useful features unavailable to users > of all other init systems. Like the upcoming wifi management changes - > those sound great, but there doesn't seem to be a reason why it > couldn't have been designed in such way that users of other init > systems could simply call some executable with some params and have > their wifi configured with those tools. I'm going to assume you're not particularly interested in hearing the Nth iteration of someone explaining reasons for such a design. > Being the default init system should not be the mandate to > break/rewrite everything else. In fact being the default init system > should bring great responsibility *not* to break stuff. First of all, software that does not work with systemd is not "broken"; it works just fine with its dependencies installed. If you want it to work with other software, that's a wishlist request, not a bug. In the more conventional sense of "break", systemd has in fact taken an extraordinary amount of care not to break stuff, frequently succeeding; I find it quite impressive how painless the transition has managed to be given the magnitude of the change. I would suggest directing your concerns either at upstreams to convince them to not use systemd functionality (good luck), or better yet into the development of alternatives that people want to use *more* than the versions in systemd. Absolutely nothing stops you. If you (and the entire set of people who agree with you) do not collectively have the time to keep up with the astonishingly rapid development pace of systemd, the right answer is *not* to hobble systemd or shout "wait up" at it, nor is it to hobble other software that wishes to use systemd until a duplicate implementation exists. - 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/20141024142725.GA16732@thin
