Bug#727708: bystander note about systemd role
Side note from bystander: in this, fascinating thread I mention one, small thing: systemd is disputed here only as primary init system. But systemd is on fast track to evolving into something bigger and larger than process supervisor - something like universal platform for LinuxOS, like - I don't know how properly describe it with one word - maybe like Android? It is not my personal impression, it was articulated - for example - by Lennart Poetering, as cited in [1]: ... Note that systemd is not an init system (since quite a while), it's a basic set of userspace tools to build an OS from. And hell yes, sane IPC is something we believe should be at the core of every OS, and hence it needs to be at the core of what systemd does. ... Also, at this moment, Debian still claims that we are trying to produce, amongst other things, a free Unix[2], but some of devs involved into systemd or kdbus development and many supporters seconded opinion that unix philosophy is dead as - for example - in following thread and mentioned LWN comments[3]. From my, humble POV, in this thread TC should also dispute about general direction for Debian project - because systemd brings more changes to whole system than - simply - removing /etc/init.d and /etc/inittab in favour of new init system alternatives. 1 - https://plus.google.com/117255203942825212306/posts/ZpW1Pa2TWin 2 - http://www.debian.org/doc/debian-policy/footnotes.html 3 - https://plus.google.com/111049168280159033135/posts/2nnvNVmAPRV Just my two cents, -- Piotr 'aniou' Meyer -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140103083146.ga11...@czajka.smutek.pl
Bug#727708: init system other points, and conclusion
On Thu, 2014-01-02 at 14:27 -0800, Steve Langasek wrote: On Thu, Jan 02, 2014 at 09:50:58AM -0700, Bdale Garbee wrote: Josselin Mouette j...@debian.org writes: It shouldn’t come as a surprise that it is hard for developers to respect the TC’s decisions when we see disrespectful sentences like the one above from some of its members. I agree. We are of course each entitled to hold opinions about such things, but I would strongly prefer if we could all try *very* hard to keep such assertions out of TC discussion. They have no place here. I recognize that we as TC members have a moral duty to not gratuitously demotivate Debian contributors. However, the duty to not alienate contributors is secondary to our duty of defending the technical integrity of Debian, and so I stand behind that comment and am going to elaborate with reference to an example so that the other members of the TC, and the GNOME team, understand exactly where I'm coming from. (The example is from a question that was referred to the TC in July 2012 - bug #681687 - so it may ring a bell for some here.) I fail to see how further digging into this topic is relevant to the discussion at hand. I would however like to state that as a member of the gnome, I've personally repeatedly been very demotivated by these lines of discussions both as part of the TC process and outside. And, again, personally, I simply tend to stay out of public discussion in Debian around gnome/systemd/pulseaudio etc as they tend to filled or at least overshadowed with assumptions of bad faith and mistrust that it takes a disproportionate amount of energy to get to any constructive conclusion if such a conclusion is at all possible. Instead i prefer to spent the little time i have for Debian on constructive things that actually benefit our users. However, again, none of this is relevant for the init system discussion. So if there is a need to continue on this topic in a constructive manner, please feel free to but lets move it out of the TC discussion. -- Sjoerd Simons sjo...@debian.org -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1388738919.2092.74.ca...@dusk.luon.net
Bug#727708: init system other points, and conclusion
On Thursday 02 January 2014 14:27:14 Steve Langasek wrote: For several years the GNOME Team ignored section 9.7 of Policy, concerning integration with the MIME handling system. They did this in favor of implementing the related freedesktop.org on the grounds that the fd.o standard is technically superior (and less work, since it was already implemented upstream). Normally my interactions with the GNOME Team is friendly mockery. But sometimes one has to stand up next to them. I've ignored the mime handling system as a part of the KDE Team. I've ignored the menu system as a part of the KDE Team. And I have a plan to even more aggressively ignore it (as in, hide it from the menu). Both things are ancient relics that should have been dealt with by removal. I tried bring the latter thru the policy process, but given one of the few people who cares strongly about the debian menu is also a policy delegate, it is just a uphill battle and much easier to just move on. But if the members of the TC do *not* think this is true - if, indeed, our collective preference is for upstart rather than for systemd - then I don't think we should be swayed by assertions that GNOME upstream is tethering itself to a specific init system It is not only GNOME upstream that is heading towards systemd as the way to do things. It is also where stuff is heading in KDE land. /Sune -- Genius, I'm not able to cancel the mousepad of a SIMM, how does it work? The point is that you neither can ever explore the analogic program, nor have to ping a printer for saving the SCSI gadget on a proxy over a parallel button. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8739372.uNbplAbK6r@dabney
Bug#727708: init system other points, and conclusion
Sune Vuorela writes (Bug#727708: init system other points, and conclusion): I've ignored the menu system as a part of the KDE Team. And I have a plan to even more aggressively ignore it (as in, hide it from the menu). Both things are ancient relics that should have been dealt with by removal. I tried bring the latter thru the policy process, but given one of the few people who cares strongly about the debian menu is also a policy delegate, it is just a uphill battle and much easier to just move on. That's a shame. The TC exists not just to contradict desktop software maintainers; our job includes contradicting policy maintainers too. And indeed if you want us to contradict the policy delegates you only need a simple majority in the committee. Our menu arrangements have been unsatisfactory for some time and I for one would certainly be open to change. Now is probably not the right time for this, but maybe after we've dealt with the init system question, you'd like to write up a summary of the situation, and propose a transition plan. If the policy editors don't see it your way this is certainly something that the TC should be interested in. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21190.43924.95484.576...@chiark.greenend.org.uk
Soften the the wording recommending menu files: let's do it in Jessie.
[dropping #727708 as it is getting off-topic] Le Fri, Jan 03, 2014 at 12:22:44PM +, Ian Jackson a écrit : Our menu arrangements have been unsatisfactory for some time and I for one would certainly be open to change. Now is probably not the right time for this, but maybe after we've dealt with the init system question, you'd like to write up a summary of the situation, and propose a transition plan. If the policy editors don't see it your way this is certainly something that the TC should be interested in. Hello Sune and Ian, The current state of #707851 (‘Soften the wording recommending menu files’) is that the proposition of Sune and Ian got a positive echo from two Policy editors. We then lost momentum, and while Bill's criticism of XDG menu specification had chilling effects on me, reading again the thread, I do not see a black-on-white refusal of the core of the proposal itself, and to be fair I need to say that the final reason why I have not pushed this work further is the lack of stimulating replies to the wording reshaped by Russ and me. I should have been more active and ping directly the participants of the discussion. Let's take it positively: with a bit of support (something like seconded, thank you) from the proponents of the change, we can move #707851 to acceptance or to a clear definition of what is considered consensus-breaking, in case there is a precise and unresolvable opposition to some of the changes. As the maintainer of the mime-support package I have some interset in #707851 and now that I stepped down as a Policy editor, I do not need to be as neutral as before. I will restart the discussion, keeping the GNOME and KDE people in the loop, in order to do what the bug title asks for: soften the wording recommending menu files. I hope that it will not be necessary to bother the TC. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140103141534.GA10529@aqwa.igloo
Bug#727708: additional OpenRC information: OpenRC now in Debian Experimental!
On 01/03/2014 01:25 AM, Russ Allbery wrote: As I mentioned in some of my previous notes, I was unable to evaluate OpenRC in a meaningful way during my general experiments for a few reasons. My impression was formed based on previous discussion and what documentation I could find, which was fairly minimal. Thomas Goirand sent me considerably more information, including some details about OpenRC project goals that corrects information in my original writeup. With his permission, I'm including that here for the benefit of everyone else who is following this debate. Thomas, please follow up with anything that I left out or anything else that you think people should be aware of. Well, there's something that people should be aware of... OpenRC is now in Debian experimental! \o/ Also: * I have solved the problem with reinstalling the initscript package (it was only a missing /etc/runlevels/single folder, which by the way is now populated with the correct symlinks so single user mode also works from now on). * The first reboot can be done using: for file in /etc/rc0.d/K*; do s=`basename $(readlink $file)` /etc/init.d/$s stop done That fits on a single line, so the postinst script of OpenRC just warns that this command should be performed by the user when migrating from sysv-rc to OpenRC. When doing this, the first shutdown is kind of clean. While not perfect (yet), that's a workaround. Unfortunately, with sysv-rc, there's no way to know which daemon is started, so it's also impossible to stop them cleanly. Though probably attempting to stop them all should work. I'm open to any suggestion to make this better, and maybe have a way to build a script that users could call directly. Note that when migrating back from OpenRC to sysv-rc, there's no such a problem, it just works (since sysv-rc is stateless). I of course welcome anyone to try OpenRC and report bugs. Cheers, Thomas Goirand (zigo) P.S: I'd like to publicly thank Patrick Lauer, Benda (李明宇), Bill Wang, Roger Leigh, WilliamH qnikst (sorry, I only know the IRC nicks of these last 2 persons) for their help and support when porting OpenRC to Debian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52c6f4f3.5020...@debian.org
Bug#727708: additional OpenRC information: OpenRC now in Debian Experimental!
Thomas Goirand writes (Bug#727708: additional OpenRC information: OpenRC now in Debian Experimental!): OpenRC is now in Debian experimental! \o/ Good, thanks. I of course welcome anyone to try OpenRC and report bugs. Can you point me to the relevant reference documentation ? Thanks, Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21190.63089.154538.739...@chiark.greenend.org.uk
Bug#727708: init system discussion status
Ian Jackson ijack...@chiark.greenend.org.uk writes: | Choice of init system: | | 1. The default init(1) in jessie will be upstart. | | 2. Architectures which do not currently support upstart should try to |port it. If this is not achieved in time, those architectures may |continue to use sysvinit. [ Non-use of upstart should not be a |criterion for architecture qualification status in jessie. ] | | 3. At least in jessie, unless a satisfactory compatibility approach is |developed and deployed (see paragraph 10), packages must continue |to provide sysvinit scripts. Lack of a sysvinit script (for a |daemon which contains integration with at least one other init |system) is an RC bug in jessie. As said elsewhere, I think there should be a paragraph about packages that depend on a specific init system for reasons other than service startup, e.g. 4. The above criterium also extends to dependencies that are not related to service startup. In jessie, no package may depend on a single initsystem other than sysvinit. After jessie, no package may depend on a single init system other than the default init. or alternatively 4. Packages may, however, depend on a specific init system (which may not be the default init) for features that are not related to daemon startup. Such packages will only be installable on systems running a non-default init, but are permitted in the archive. Best, Nikolaus -- Encrypted emails preferred. PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k3ehaqqu@rath.org
Bug#727708: init system discussion status
On Fri, 2014-01-03 at 10:02 -0800, Nikolaus Rath wrote: Ian Jackson ijack...@chiark.greenend.org.uk writes: | 3. At least in jessie, unless a satisfactory compatibility approach is |developed and deployed (see paragraph 10), packages must continue |to provide sysvinit scripts. Lack of a sysvinit script (for a |daemon which contains integration with at least one other init |system) is an RC bug in jessie. As said elsewhere, I think there should be a paragraph about packages that depend on a specific init system for reasons other than service startup, e.g. Even restricted to just service startup, I think that's a rather strict limitation. Suppose an upstream releases a new daemon that is intended to be used with systemd using socket activation, and as such does not contain any code to do double-forking or open listening sockets. Would it be forbidden to package this daemon in Debian unless the maintainers are willing to add forking, other startup and socket code as Debian- specific patches? If it would, how much functionality would the maintainers need to add for a minimal accepted version - for example would they need to add new options to specify which port to listen on, or is opening a hard-coded default port enough for the added socket code? Adding support for everything that systemd socket activation automatically supports would not be realistic. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1388775476.3938.447.camel@glyph.nonexistent.invalid
Bug#727708: init system discussion status
Nikolaus Rath writes (Bug#727708: init system discussion status): As said elsewhere, I think there should be a paragraph about packages that depend on a specific init system for reasons other than service startup, e.g. I agree with this. 4. The above criterium also extends to dependencies that are not related to service startup. In jessie, no package may depend on a single initsystem other than sysvinit. After jessie, no package may depend on a single init system other than the default init. I don't think the default init should have an exception. The alternative is that installing such a package might switch your init system to satisfy the dependencies! And I think all these bugs should be RC. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21191.2654.747510.242...@chiark.greenend.org.uk
Bug#727708: init system discussion status
Russ Allbery writes (Bug#727708: init system discussion status): The thrust of this seems right, but I dislike telling people what to do. Can we recast this in a way that avoids that problem? Maybe something like: Sure. I borrowed your text and edited it slightly for clarity. I also changed upstart/systemd to upstart, for two reasons: one is that at this stage I'd prefer to try to maintain only one version of this text. And the other is that IMO the proposed prescription for non-Linux ports doesn't make sense for systemd. There is little prospect of systemd being ported to those systems. Ian Jackson ijack...@chiark.greenend.org.uk writes: | 3. At least in jessie, unless a satisfactory compatibility approach is |developed and deployed (see paragraph 10), packages must continue |to provide sysvinit scripts. Lack of a sysvinit script (for a |daemon which contains integration with at least one other init |system) is an RC bug in jessie. This needs the same exception as is currently in Policy 9.11, namely: An exception to this rule is scripts or jobs provided by the init implementation itself; such jobs may be required for an implementation-specific equivalent of the /etc/rcS.d/ scripts and may not have a one-to-one correspondence with the init scripts. I've written a version of Niklaus's rule about dependencies: Likewise, packages must not Depend on or Recommend (directly or indirectly) a specific init(1). Violations of this are also an RC bug in jessie. And: Theses rules do not apply to machinery which itself forms part of the implementation of one or more init systems. That seems to be the clearest way to put the matter. Should delay is a bit strong given that we have many packages in the archive that already provide native support for upstart, and several (including ones maintained by both Colin and myself) that have native support for systemd. Maybe something more like: Contributors who have not already added native support for upstart, systemd, or OpenRC may wish to wait until the relevant Debian Policy is declared, by the Policy editors, to be ready. Early adopters should be aware that the requirements may change and their packages may require updates. I like this and have included it. |(b) Use facilities documented in the reference manuals for the init |system in question (as found in sid). [ This requirement |cannot be met until the init system has a suitable reference |manual. ] | |(c) Require that environment variables and fds involved in the |daemon startup protocol should not in general be inherited by |the daemon's descendants. | |(d) Forbid the introduction of embedded copies of library code |(or the use of any embedded copies included by upstream). I'm not sure what the point of (b) is. I think (d) is too strong. Policy 4.13 currently says: (b) is probably irrelevant given the rest of the resolution. I have deleted it but not (for now) renumbered the rest. If (d) is removed from here then I think it needs to be included in 6C. I think Policy 4.13 already covers this adequately and we don't need to say anything further in the decision. I would like to be clear that maintainers don't need to take patches that introduce embedded copies of sd_notify. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21191.6773.303541.83...@chiark.greenend.org.uk
Bug#727708: init system thoughts
Steve Langasek vor...@debian.org writes: The purpose of failsafe.conf is to ensure that services which have not been converted to the native format, but instead provide initscripts that are called upon reaching runlevel 2, are started at the right time - so that they aren't unreliable due to racing the network stack. This is an existing bug on sysvinit systems, but the race is hit much less frequently there because sysvinit is slower. Okay, thanks, that's pretty much what I'd thought. Yes, that's what in systemd one should address via network-online.target and some sort of local integration that implements whatever network is up policy that you want to enforce. Given that ifupdown is still by far the best way to manage networks on servers, and most of these init issues are most likely to happen on servers, I think we should add some sort of ifupdown integration with the network-online.target in the Debian systemd package that matches Debian's current definition of the LSB $network target. systemd's upstream is entirely correct that $network is rather underspecified from an LSB perspective, but Debian *does* have a definition, and the principle of least surprise says that we should duplicate that definition in a new init system. I assume that's what failsafe.conf is effectively doing for upstart. I am left with the concern that I seem to be the first person to ask this question, in discussions with the TC, six months after AIUI the systemd maintainers considered systemd ready to be made the default. Well, one, that's why we have these discussions. More eyes on things like this are going to find issues that we need to deal with. And your expertise in the sorts of issues Ubuntu encountered is very helpful. And, second, we're talking about problems that will happen with badly written local init scripts and are less likely to happen with packages in the archive (which are more likely to be well-written). I'm not particularly surprised that systemd early adopters don't have a lot of badly-written local init scripts that they continue to use. So I fear that switching to systemd by default is going to result in easier package maintenance for early adopters, but a much buggier experience for our users. If we decide for systemd, what do you think is the right way to mitigate such problems for jessie? Some of these issues are only going to be seen once people start making use of systemd in anger with their existing server configs (e.g., an ec2 VM with a simple disk and network config is not going to expose these problems), and I don't really think we want to do this by way of switching the default in unstable and waiting for the bugs to roll in. I think there are multiple tiers of answers to this question. Changing init systems is going to be disruptive. There's simply no way around that. It was disruptive when we switched to dependency-based boot, which also surfaced tons of problems with local init scripts and caused a lot of users to complain. It's going to be disruptive when we switch to any other new init system. That's just the nature of the beast. This is one of the reasons why I think we should support booting jessie with sysvinit. This parallels the migration path that we took for dependency-based boot. We make it clear what the new default is, but if people run into trouble, they can always fall back to sysvinit to get their stuff working again. It gives people a release cycle of leeway before they *have* to make sure their systems work with the new init system since, indeed, problems with local hacks are unlikely to start showing up until we release the new init system in stable. I therefore think we should use a very similar approach to what we did with dependency-based boot. We're already in the first stage of that: systemd is available as an option in unstable. A bunch of people are using it, and have been using it for a while, and are reporting problems. The next step will be to start pushing for broader adoption, and possibly, if we can figure out a good way to do it so that people can switch back, have dist-upgrade switch systems to systemd. (Of course, we would do this after we've hammered out the Policy work.) Then, when we release, there will obviously need to be a discussion of this in the release notes, as well as instructions on how to fall back to sysvinit, and possibly additional notes about common problems based on what we uncover from early upgrade reports. So, in other words, I do think a large component of the solution is to, indeed, switch in unstable and let the bugs roll in, which is how Debian tests everything. We can stage things somewhat more (for example, I think we should actively encourage Debian developers to switch to the new default in advance and report problems), but at the end of the day that's going to be a large part of the testing process, just like it was with dependency-based boot. Now, you are entirely correct that
Bug#727708: init system thoughts
Russ Allbery r...@debian.org writes: However, that said, I believe the integration of systemd will actually be easier in the long run because upstart is rather... weird. On that front, I also wanted to ask about: https://bugs.launchpad.net/upstart/+bug/447654 If I'm understanding this bug correctly, it's another case where upstart's dependencies work (at least currently) in rather surprising ways that you have to understand fairly well to work around. But I wasn't sure if this was just a stray left-over bug for an issue that hadn't yet been resolved, so I wanted to keep it separate from the broader argument. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k3egljc5@windlord.stanford.edu
Bug#727708: init system discussion status
Ian Jackson ijack...@chiark.greenend.org.uk writes: Sure. I borrowed your text and edited it slightly for clarity. I also changed upstart/systemd to upstart, for two reasons: one is that at this stage I'd prefer to try to maintain only one version of this text. Yeah, that's fine. We can hammer out the details of one path, and then figure out whether it makes sense to have the systemd path be a completely separate writeup or whether it should be presented in the form of an amendment. And the other is that IMO the proposed prescription for non-Linux ports doesn't make sense for systemd. There is little prospect of systemd being ported to those systems. I'd prefer to leave it in. Upstream's opinions aside, systemd is free software and if someone wants to try to port it (or, possibly more likely, port it by writing something native that provides the same interfaces), they can. Maybe upstream is right and it's untenable; maybe they're wrong and it's not as hard as they think. I realize it's horribly unlikely for jessie, but still, as a matter of principle, I'd rather encourage the same software or at least the same interfaces across all of our ports. But, anyway, we can focus on the upstart position first and deal with that later. I've written a version of Niklaus's rule about dependencies: Likewise, packages must not Depend on or Recommend (directly or indirectly) a specific init(1). Violations of this are also an RC bug in jessie. And: Theses rules do not apply to machinery which itself forms part of the implementation of one or more init systems. That seems to be the clearest way to put the matter. This seems fine to me, at least for right now. I'm doing a bit of additional research right now to be sure that I understand the implications of this and may end up asking for any problems that anyone is aware of with this approach, just to be sure we're not missing something. I think Policy 4.13 already covers this adequately and we don't need to say anything further in the decision. I would like to be clear that maintainers don't need to take patches that introduce embedded copies of sd_notify. Oh, okay. I had missed that aspect of things. I think it's fine to be clear about that as long as we're not prohibiting via non-advice TC decision using an embedded copy (which feels like bug severity inflation to me). -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vby0k295@windlord.stanford.edu
Bug#727708: init system discussion status
Uoti Urpala uoti.urp...@pp1.inet.fi writes: One case to consider is what should happen with GNOME if it requires interfaces that nobody has implemented for sysvinit. The likelihood of this and possible impact is one of the things that I'm checking on. I'd rather not have the argument if it turns out not to be something we have to worry about for the jessie release. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87a9fcjwox@windlord.stanford.edu
Bug#727708: init system discussion status
On Fri, Jan 03, 2014 at 10:02:01AM -0800, Nikolaus Rath wrote: As said elsewhere, I think there should be a paragraph about packages that depend on a specific init system for reasons other than service startup, e.g. 4. The above criterium also extends to dependencies that are not related to service startup. In jessie, no package may depend on a single initsystem other than sysvinit. After jessie, no package may depend on a single init system other than the default init. or alternatively 4. Packages may, however, depend on a specific init system (which may not be the default init) for features that are not related to daemon startup. Such packages will only be installable on systems running a non-default init, but are permitted in the archive. As loath as I am to participate in this discussion, I have to ask if your intent is to suddenly outlaw all the packages which depend on runit. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140104030651.ga29...@scru.org
Bug#727708: init system discussion status
Clint Adams cl...@debian.org writes: As loath as I am to participate in this discussion, I have to ask if your intent is to suddenly outlaw all the packages which depend on runit. I don't think runit (or daemontools) are init systems. If you feel like that may be ambiguous, we should say that explicitly. (This is one of the problems with how to word matters around OpenRC, since in a way it's actually closer to daemontools or runit. The latter just never attempted to deal with *all* the startup scripts.) Regardless, yes, we definitely should not outlaw packages that depend on runit as part of this decision. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wqigigfs@windlord.stanford.edu
Re: Bug#727708: init system discussion status
Clint Adams wrote: On Fri, Jan 03, 2014 at 10:02:01AM -0800, Nikolaus Rath wrote: As said elsewhere, I think there should be a paragraph about packages that depend on a specific init system for reasons other than service startup, e.g. 4. The above criterium also extends to dependencies that are not related to service startup. In jessie, no package may depend on a single initsystem other than sysvinit. After jessie, no package may depend on a single init system other than the default init. or alternatively 4. Packages may, however, depend on a specific init system (which may not be the default init) for features that are not related to daemon startup. Such packages will only be installable on systems running a non-default init, but are permitted in the archive. As loath as I am to participate in this discussion, I have to ask if your intent is to suddenly outlaw all the packages which depend on runit. I think it'd be appropriate to allow dependencies on runit (or another package that contains an implementation of /sbin/init), as long as either the depending package doesn't depend on having /sbin/init be that init (which holds true for runit), *or* if an alternative package exists to integrate with the default init system. For instance, git-daemon-run versus git-daemon-sysvinit versus a hypothetical git-daemon-systemd, or a future gnome-session-systemd or gnome-session-upstart package (for whichever init system isn't the default). (Note that the latter would work better if upstart stopped conflicting with sysvinit, similar to how systemd can be installed without being init.) - Josh Triplett -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140104033210.GA17653@leaf
Bug#727708: init system discussion status
On Fri, Jan 3, 2014 at 7:17 PM, Russ Allbery r...@debian.org wrote: Clint Adams cl...@debian.org writes: As loath as I am to participate in this discussion, I have to ask if your intent is to suddenly outlaw all the packages which depend on runit. I don't think runit (or daemontools) are init systems. If you feel like that may be ambiguous, we should say that explicitly. (This is one of the problems with how to word matters around OpenRC, since in a way it's actually closer to daemontools or runit. The latter just never attempted to deal with *all* the startup scripts.) Upstart running as a session init is not really an init system either, then, under that definition. Perhaps we should ban packages that depend on a certain init system being PID 1. Upstart, runit, daemontools, Circus, God etc. can run as session inits on top of any other init system, and therefore will have a small, confined effect when doing so and should be allowed. Regards, Cameron
Bug#727708: init system discussion status
Clint Adams cl...@debian.org writes: On Fri, Jan 03, 2014 at 10:02:01AM -0800, Nikolaus Rath wrote: As said elsewhere, I think there should be a paragraph about packages that depend on a specific init system for reasons other than service startup, e.g. 4. The above criterium also extends to dependencies that are not related to service startup. In jessie, no package may depend on a single initsystem other than sysvinit. After jessie, no package may depend on a single init system other than the default init. or alternatively 4. Packages may, however, depend on a specific init system (which may not be the default init) for features that are not related to daemon startup. Such packages will only be installable on systems running a non-default init, but are permitted in the archive. As loath as I am to participate in this discussion, I have to ask if your intent is to suddenly outlaw all the packages which depend on runit. Are you asking me personally? No, that's not my intent. I merely think that a CTTE solution should spell out precisely to what extent a package must be compatible with the default init (i.e., if it must be fully working with the default init, or if it only has to provide daemon startup/supervision/shutdown for the default init). This is why I explicitly listed two conflicting, alternative wordings. Best, Nikolaus -- Encrypted emails preferred. PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mwjc2x0j@vostro.rath.org
Bug#727708: init system other points, and conclusion
On 31 December 2013 12:32, Steve Langasek vor...@debian.org wrote: I agree that maintaining a systemd unit plus an upstart job is better than maintaining an init script. I just can't see any way through to a world where these will both actually be maintained (the testing problem), particularly if upstart use is relegated to the non-Linux ports. I wonder if folks could clarify what status they expect secondary init systems to have in Debian? To me, the above seems similar to saying I just can't see any way through to a world where both exim and postfix, or apache and nginx will both actually be well supported in Debian -- choosing an MTA or web server is something we leave up to the sysadmin, even if we choose defaults at install time, and packages that use their services are generally expected to work well with whatever the sysadmin chooses. That's obviously not the case for every package, some provide modules for apache but not nginx say (libapache2-mod-*), and others are specifically for postfix and won't work with exim (pmailq, postfwd, postgrey eg), but packages that just want to call sendmail or provide a cgi script are expected not to care. Similarly, choosing Gnome as the default desktop for Debian doesn't mean you can't reasonably use KDE or XFCE on your Debian system. For postifx/exim and apache/nginx I don't think you have to have any elements of the other system installed to run your preferred system; I'm not sure that's so true for KDE or XFCE though -- certainly I use packages that pull in libgtk (groff, gnuplot, emacs, evince) and libgnome (inkscape?) on my XFCE system, for instance. Maybe this should be different for systemd/upstart -- maybe they're more like dpkg/rpm or apt/yum -- you can certainly install all four on your Debian system, but two of them aren't so useful for actually managing it. That /seems/ like an undesirable situation though -- certainly it seems like there are a bunch of people who'd like to run systemd on Debian, a bunch who'd like to run upstart on Debian (Canonical if no one else), and at least a few that might like to run something else (OpenRC users, kfreebsd/Hurd folks). Are the obstacles to supporting that really infeasible/insurmountable? Wouldn't it be reasonable to do something like piuparts in EC2 to test packages under different /sbin/init providers to see if they behave roughly as expected? (Is it really harder to have upstart and systemd support in Debian than it is to support running Debian on either a Linux, FreeBSD or Hurd kernel? All those things are already possible anyway, aren't they?) It's hard for me to view Ubuntu, Debian GNU, and Debian GNU/kFreeBSD use upstart; Red Hat, Fedora, SuSE, and Debian GNU/Linux use systemd as anything but a loss for upstart. With only non-Linux ports of Debian on upstart's side and all the other potential collaborators among the traditional distros opting for systemd, I think that would leave Canonical confronting some hard questions about whether to continue investing in upstart development. (So, uh, that would mean that a Canonical-employed maintainer of upstart would have a fairly challenging conflict of interest in this decision, right?) My answer to this is that, as things stand today, this argument does *not* apply, because Debian hasn't made a choice for either systemd or upstart yet. Whichever option Debian chooses, that is the option that is going to carry the day, because Debian does integration better, and across a wider range of software, than any other distro out there. So that's not true of apache/nginx, exim/postfix, or Gnome/KDE. I've seen some argue recently that it's true for dpkg/rpm, but only post-Ubuntu -- prior to that I think I only saw that claim in reverse. It doesn't really strike me as a great argument as a consequence. So I don't think I would vote systemd on linux, upstart on non-linux above systemd, non-linux ports to figure out how to be compatible, because I fear that would be leading the non-Linux ports on. I would vote Gnome on Linux, XFCE/fvwm on non-Linux over Gnome on Linux, non-Linux ports have no desktop until they figure something out quite happily. That only works because XFCE/fvwm are entirely plausible options on Debian with a Linux kernel, though, and only works well because there are standards for packages to tell desktops how to add them to their menus. (As a personal aside, whichever of upstart and systemd is chosen by the TC as the default, I intend to wholeheartedly adopt it for my own use in Debian. I love the upstart codebase, for all the same reasons that you found when you looked at it, but I'm not on a quixotic quest here. If Debian chooses systemd, then any time I spend on debugging init system bugs in Debian is best spent debugging them on systemd, where it will bring the most benefit to our users.) For comparison: 1771 task-gnome-desktop 35102 0 0 0 35102 (Debian Install System Team) 2460
Bug#727708: init system other points, and conclusion
Anthony Towns a...@erisian.com.au writes: I wonder if folks could clarify what status they expect secondary init systems to have in Debian? My personal answer to this is that I truly don't know. On one hand, we have four different init systems in Debian right now, plus a fifth in experimental, and several of them have been in Debian for a number of years. So clearly it's currently possible to have multiple, working init systems. At least three of them (upstart, systemd, and sysvinit) work reliably well in Debian right now. Some, although not very many, packages have been converted to support upstart, systemd, or both already. On the other hand, much of why those init systems work is that we have the lowest-common-denominator of init scripts in all packages. I suspect, although am not sure, that a noticable amount of the long-tail software in Debian will only work with the default init system. In any case where the packager primarily cares about getting the software into Debian, not about broader Debian project goals for the sake of doing things for Debian, I'm not sure there's going to be much incentive to add support for the other init systems, and I'm not sure there's going to be the resources to submit them as patches. Left to itself, I think the best case that we'll get for support for alternative init systems will be at the level of our manpage coverage: we never achieve it, but we don't do a horrible job. It's not clear to me that would be a bad outcome. I think with a concerted effort on the part of porters (most likely the non-Linux porters), we could do better than that for one alternative init system, but it would involve a lot of pestering people, which is generally not that fun and rather demotivating. I think we have a substantially higher chance of effectively supporting multiple init systems if none of them are sysvinit, because init scripts are awful from a package maintainer's perspective. But all of this is pure speculation. I really hate making people unhappy, and I really hate seeing people's work left behind, so I love the vision of a world in which we can actually support a multitude of init systems. But I'm not sure how realistic it is to expect enough package maintainers to care. Personally, as much as time permits, I intend to support all init systems that anyone in Debian is interested in, at least to the extent of providing untested configurations for those init systems. I don't know if I'll be able to follow through on that. Certainly, for simple daemons, I can throw something together and be pretty sure it will work even though I didn't test it. The real test will be supporting something like openafs-client on an init system that I don't use. I would like to do that, but I'm not sure that I will find the time in practice. But certainly if someone else provides the patches, I'll apply them. There are also some packages that have very complex initialization requirements or that tie heavily into the early boot. Those are going to be a harder challenge than the average daemon, since they're likely to have specialized startup code that will have to be rewritten in multiple ways for different init systems. For example, if we choose systemd, I expect and hope that many of our hardest and most complex cases will migrate to socket activation, which should make them far more robust and much simpler to maintain. Once one has converted a complex and racy startup to race-free and simple socket activation, I know it's going to be hard to find the mental effort required to maintain the sysvinit scripts or fix corner-case ordering bugs that socket activation just make disappear. Forced to make a choice, should Debian go for smoother/tighter integration between apps, or more choice for users/sysadmins? I'd expect Debian to choose the latter; though Ubuntu, Red Hat and possibly Fedora might choose the former. Well, here again, all of the above is the most attractive answer to me. But my background, experience, and day-to-day work with Debian leads me to choose an option that isn't on that list: more power, simpler configuration, simpler management, and more directly useful features for sysadmins. A world in which all services provided by Debian are started with socket activation via configuration with a simple local override mechanism is hugely attractive from an enterprise systems administration perspective. Socket activation is, I think, the biggest place where less capable init systems are in danger of getting left behind. Once you have that feature available, it solves so many problems that it's annoying to have to work without it. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8761q0i6l1@windlord.stanford.edu
