Bug#727708: init system discussion status
On Sun, Jan 05, 2014 at 12:16:58AM +0100, Zbigniew Jędrzejewski-Szmek wrote: git notes are used to mark backport-worthy commits. See http://lists.freedesktop.org/archives/systemd-devel/2013-September/013188.html. We currently mark patches as bugfixes (which includes fixes for bugs present in the latest release, but not those introduced later), or documentation and performance improvements. Fedora 19 appears to be packaging patches from v204-stable branch which I can't find anywhere public. It's my private branch I generate Fedora packages from [1]. It's the same content as in Fedora git repos [2], but in a more convenient form for me. I talked with other systemd maintainers in Fedora about making it more official and public, but we haven't found the time to do it yet. If it was to be useful to other people, it can certainly be done. [1] http://kawka.in.waw.pl/git/systemd/ [2] http://cgit.freedesktop.org/systemd/systemd/ Hi, stable branches have a new official home: http://cgit.freedesktop.org/systemd/systemd-stable/ The policy wrt. to bugfixes and stable branches is described in http://www.freedesktop.org/wiki/Software/systemd/Backports/. Zbyszek -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
Keith Packard writes (Re: Bug#727708: init system discussion status): I feel that having the Debian community endorse software where a CLA is involved will tacitly encourage developers to enter into those agreements so that their work can be published as widely as possible. I can see the force of this point. Could we address this by adding something explicit to the TC resolution ? N. We are firmly opposed to Canonical's upstart Contributor Licence Agreement. As with any other program in Debian whose upstream has controversial copyright practices, the Debian project will continue accept and deploy useful patches whose contributors decline to enter into unfair copyright agreements. We recommend that Debian contributors do not sign the CLA, even when contributing changes which might be widely useful. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
* Ian Jackson (ijack...@chiark.greenend.org.uk) [140120 12:27]: Keith Packard writes (Re: Bug#727708: init system discussion status): I feel that having the Debian community endorse software where a CLA is involved will tacitly encourage developers to enter into those agreements so that their work can be published as widely as possible. I can see the force of this point. Could we address this by adding something explicit to the TC resolution ? N. We are firmly opposed to Canonical's upstart Contributor Licence Agreement. As with any other program in Debian whose upstream has controversial copyright practices, the Debian project will continue accept and deploy useful patches whose contributors decline to enter into unfair copyright agreements. We recommend that Debian contributors do not sign the CLA, even when contributing changes which might be widely useful. Though I personally agree with all those sentences I think for an official tech ctte resolution I prefer to not have the last sentence there (or move the not in front of recommend, because that's not as active as that). Perhaps something as: We do not endorse the use of licenses such as CLA, even if the software as distributed by Debian is Free Software and can be distributed and modified as usual. (or so). Andi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
On Mon, Jan 20, 2014 at 11:23:39AM +, Ian Jackson wrote: Keith Packard writes (Re: Bug#727708: init system discussion status): I feel that having the Debian community endorse software where a CLA is involved will tacitly encourage developers to enter into those agreements so that their work can be published as widely as possible. I can see the force of this point. Could we address this by adding something explicit to the TC resolution ? N. We are firmly opposed to Canonical's upstart Contributor Licence Agreement. As with any other program in Debian whose upstream has controversial copyright practices, the Debian project will continue accept and deploy useful patches whose contributors decline to enter into unfair copyright agreements. We recommend that Debian contributors do not sign the CLA, even when contributing changes which might be widely useful. I would prefer to see more neutral wording, something to the effect of: The Technical Committee does not endorse the use of a CLA by the upstart project, which causes barriers to contributions from the wider Free Software community, and this decision is not a recommendation that Debian contributors sign the CLA. I.e., rather than a positive recommendation to contributors about what licensing agreements they should choose to engage in (which I don't think it's the TC's place to do), a softer call-out to make it clear that this is not an endorsement of CLAs. But perhaps this doesn't satisfy Keith's concern. (Perhaps neither wording does.) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#727708: init system discussion status
Steve Langasek vor...@debian.org writes: I would prefer to see more neutral wording, something to the effect of: I didn't mean that the TC decision should mention the CLA. I don't think that's an appropriate place for this kind of statement. -- keith.pack...@intel.com pgpixwDU4Pjfm.pgp Description: PGP signature
Bug#727708: init system discussion status
Keith Packard writes (Bug#727708: init system discussion status): In contrast, upstart has a developer community limited to Canonical employees and others who are able and willing to sign the onerous CLA associated with that software. [...] You said on IRC that the CLA was an important factor for you. I'm going to make an attempt to persuade you that this is not a big problem for Debian. Firstly, I should say that I think the CLA is utterly ridiculous. I want to be completely clear that like almost everyone else in this conversation, I would certainly not sign it. But: I think you overestimate the likelihood of Debian being on the losing end of a fork. If we adopt upstart as default in Debian, I expect we will accumulate a number of important (CLA-less, obviously) patches in the Debian package. Debian will be an attractive place even for non-Debian users to submit patches for the precise reason that we don't insist on unjust copyright arrangements. In fact, I would expect much of the serious development to take place in Debian's version. Finally, we shouldn't be afraid of the scenario where the Debian version ends up being de facto the upstream. We have become the upstream for numerous programs of comparable size. And, to put my time where my mouth is, I'm willing to step up and contribute patches and help maintain the Debian upstart package. Personaly I think upstart has the right approach and I think improving it sounds like fun. Like Andi, I think the risk to our autonomy from upstream is much lower in the case of upstart than systemd. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
Ian Jackson ijack...@chiark.greenend.org.uk writes: Firstly, I should say that I think the CLA is utterly ridiculous. I want to be completely clear that like almost everyone else in this conversation, I would certainly not sign it. It's divisive, and has already managed to fragment the community into two camps. As Kay said (in google+, alas): https://plus.google.com/u/0/+KaySievers/posts/C3chC26khpq The development of systemd was, at least in part, due to the CLA. The result was that the bulk of ongoing init system work moved away from upstart and towards systemd. Free software developers gain value in proportion to the number of people sharing and using their code. Failing to enter into a CLA limits the potential market for contributions. I feel that having the Debian community endorse software where a CLA is involved will tacitly encourage developers to enter into those agreements so that their work can be published as widely as possible. Personally, I would like us to take a principled stand against corporate-sponsored CLA-restricted software projects as I feel they do not follow the spirit of the DFSG, even as they follow the letter. They remind me too strongly of Animal Farm. Like Andi, I think the risk to our autonomy from upstream is much lower in the case of upstart than systemd. Certainly the fraction of Debian influence in upstart would be dramatically larger than our influence could be in systemd as so many fewer people outside of Debian are working on upstart than systemd. A significant benefit of systemd is precisely that a lot of other people are working on it, and appear willing to continue working on it. The best way to make Debian gain relevance and importance there will be to increase the number of Debian developers actively participating in improving it. If autonomy from other distributions was an explicit Debian goal, then we'd presumably be spending a lot more time cleaning up the Hurd instead of collaborating with others on Linux. -- keith.pack...@intel.com pgpQaC9UuAnbI.pgp Description: PGP signature
Bug#727708: init system discussion status
Ian Jackson ijack...@chiark.greenend.org.uk writes: Andreas, Bdale, Don, Keith: please let us know what you're thinking, and what more information/discussion would be useful. As the newest TC member, I hope to emulate my learned colleagues and try to keep the discussion moving in a positive direction. First off, my personal interest and experience with init has been limited; starting off my Unix life doing system administration on a PDP-11 running V7 and then 2.7 BSD, and then rapidly escaping into desktop system software development has never made me comfortable with our current sysvinit-based systems. I suspect I've spent more time in the last six months exploring this space than I did in the previous 32 years of Unix experience... As with any core system component, I believe we need to find a solution which best meets the following goals: 1) Technical excellence. 2) Support for the whole Debian community. 3) Sharing with other Linux communities. Sometimes it is possible to find a single solution which is obviously the best in all of these areas, but in this case, we will need to compromise -- none of the proposed solutions ranks number one in all three areas. Because of the central nature of pid 1, and influenced by experiences like that expressed by Marc Merlin, I believe that Debian will need to support multiple init systems going forward, even on Linux. However, on Linux, I believe that the vast majority of Debian users would be best served by encouraging them to use systemd by making that the default. systemd is being developed by a broad cross-distribution community who are solving long-standing technical issues with how subsystems are managed within the Linux environment. Yes, there are technical issues with using systemd in a Debian environment, but I don't see any of them as significant blockers, and only by contributing our expertise can we expect them to be resolved in the best way. In contrast, upstart has a developer community limited to Canonical employees and others who are able and willing to sign the onerous CLA associated with that software. I believe as a result, upstart development has flagged and now lags far behind systemd in several key areas. I would like to encourage the OpenRC community to continue working on their most excellent system though; I feel like it has a great place as a simpler and more portable system for use in environments like that described by Marc Merlin in his LCA talk discussed here recently, as well as in non-Linux environments. Thanks to Ian, Russ and Bdale for offering their opinions on this matter, it's certainly helped focus my thoughts on the one or two key points that matter most to me. And, thanks to Steve for creating a couple of virtual hosts for me to play with both upstart and systemd. -- keith.pack...@intel.com pgpnwC2riLy9d.pgp Description: PGP signature
Bug#727708: init system discussion status
]] Dimitri John Ledkov Fedora/RPM based distributions are significantly different, thus it is inevitable that we'll have to maintain a fork of systemd for best integration into Debian. This does not seem evident from the current systemd maintainers, which file bugs to disable/remove/override debian functionality and components with inferior systemd counterparts. Can you provide bug numbers for those allegations, please? http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;bug=716812 Not sure why you mention this. It's filed by a user, not anybody who's maintaining systemd. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719738 - udev follow upstream change, granted, steps have later been taken back to preserve backwards compat. Not sure how «please enable upstream functionality so lvm2 doesn't hold up the boot» becomes «disable/remove/override debian functionality with inferior systemd counterparts». Josh explains this pretty adequately in his mail. I've downloaded systemd_204.orig.tar.gz from debian mirror - 3ba441b51a390c6afc21e9a8a4811698 And i've downloaded systemd-204.tar.xz from systemd upstream - a07619bb19f48164fbf0761d12fd39a8 Ah, it seems like the last upload was done wrongly somehow. I'll see what we can do to fix that. As you can see if you browse your local mirror, there's a .tar.xz there too with a hash that matches upstream. Thanks for noticing this. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
On Sun, 2014-01-05 at 02:18 +, Dimitri John Ledkov wrote: On 5 January 2014 01:46, Russ Allbery r...@debian.org wrote: Dimitri John Ledkov x...@debian.org writes: Imho that's a gross overstatement. Over more than a year, an Ubuntu GNOME team was established and became official ubuntu flavour with so goal and purpose of shipping GNOME3 in it's full glory. If distro watch is any indication they are fast growing ubuntu flavour, outpacing the more established ones like e.g. Xubuntu. The demand for such flavour is growing, with highly positive reviews from critics and general public. There is a group of volunteers who contribute to making it work. I've personally used it, and it's quite wonderful and capable desktop environment. I think there is some degree of heresy to claim that GNOME3 is only supported with systemd-init pid1. That was the case intermittently, until majority of pid1 checks were replaced by more correct ones. Insofar as this is evidence that it's possible to make GNOME work with option 2 (run logind without systemd), this is certainly valid information, but I think this is information that we already have. As I said in my original writeup, I believe the main challenge with option 2 for jessie is not in figuring out *how* to do the work, but in identifying *who* is going to do the work. (Beyond jessie, this will require ongoing resources to maintain if it's not purely a transitional issue, but that's a somewhat separate discussion.) And I'll note that Sjoerd said exactly the same thing. Saying that it's easy is fine, particularly if you have details as to why it's easy. What we're not going to do is say that therefore the existing GNOME maintainers in Debian must do it. That is not how we work as a project, and that is not how we're going to work as a project. If they don't want to do the work, no one is going to force them to do it. Please instead note Steve's comments on maintaining logind as a separate package, which is the productive way forward and is a way to get to the second solution in my original message. Volunteering to do the work and finding a way to do it in a minimally intrusive fashion is the way to show that it's straightforward. I see thanks. I guess the only relevant addition, is that there is a pool of self-selected developers that are working on the similar type of integration issues: GNOME3 with logind without systemd-init. The Ubuntu GNOME team (packaging team is 18 people at the moment, there are more in users/qa/documentation teams ~250+ people) https://launchpad.net/~ubuntu-gnome-packaging I think as the Debian gnome team we've got a pretty good working relationship with some developers in that team, (with some developers even contributing directly to both teams! Which is great). So I'm well aware of its existance. Maybe just to clarify a bit more, _most_ of my statement was about the case where we would _not_ have systemd-logind available at all unless the default init system is PID 1. If it is available in some form it's a quite different story from an integration point of view, which Ubuntu and the Ubuntu gnome team prove. That's why i started my earlier reply in this thread by saying that it boils down to whether we can rely on systemd-logind being available :) However there is a second important difference here, which i think is worth highlighting. In the Ubuntu Gnome team, the system configuration that team supports may not be what upstream Gnome supports but it is the default Ubuntu configuration which is what all Ubuntu Gnome users actually use. So that team can focus on polishing purely that one setup. In this case the question is not about supporting Debians defaults configuration, but _additionally_ supporting a fallback configuration which hopefully only a very very small amount of users are forced to use. In the case logind can be assumed, I'm reasonably confident we can provide an at least somewhat functionally Gnome 3 for these users. However, we most likely wouldn't go to the effort of making it fully functional simply because it's both a corner case and missing someone willing to do that job test it maintain it. -- Sjoerd Simons sjo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
Le samedi, 4 janvier 2014, 19.10:21 Josh Triplett a écrit : Dimitri John Ledkov wrote: Rejections on mailinglists and else where to split: /lib/systemd/systemd-multi-seat-x /lib/systemd/systemd-timedated /lib/systemd/systemd-localed /lib/systemd/systemd-logind /lib/systemd/systemd-hostnamed from systemd package to individual packages binary packages, or at least together but separate from systemd-init. Based on the most recent mailing list discussions, it sounds like the concern there is not whether to split but who will do the work of maintaining the patches needed to make these run without systemd, since there's no point in splitting them otherwise. I think splitting these in different binary packages would make some sense anyway, even without them being ready to work without systemd (given that the reverse is true; that systemd works without each of them): it would allow packages (functionally) depending on a particular systemd interface (such as -logind, or -hostnamed, etc) to (packaging- wise) depend on the exact packages providing these, bringing more granularity and clarity to the $package depends on systemd by expressing which interfaces are concretely needed for each package. ( Then, until these are made to work without systemd, they would of course depend on the systemd package. This would also only bring on people's systems the systemd sub-parts that are actually needed for their setup. ) What I don't know is whether systemd is ready (or can easily be made ready) to work without some of these services. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#727708: init system discussion status
Le dimanche 05 janvier 2014 à 01:37 +, Dimitri John Ledkov a écrit : Patching upstream unit files to change paths is trivial, but even better would be to convince upstream to substitute in the proper path when building the unit file. Oh that indeed would be wonderful, why did systemd upstream advocate for hardcoded paths in so many projects then, instead of atleast runtime detected?! How is this suppose to work with 3rd party recompiled packages and e.g. installed in opt? previously just adding opt to PATH, or droppings things into /usr/local/, enabled to use custom compiled ad-hoc replacements as desired by deployments. blah.service.in: ExecStart=@bindir@/blah --no-fork How complicated is that? -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
Hello, On Sat, 04 Jan 2014 16:46:28 +0100 Josselin Mouette j...@debian.org wrote: I think systemd-ui is part of the systemd init system so falls into the exception. Of course that means that nothing else should depend (functionally or in package dependencies) on it. There is no way that, for example, some of the GNOME control center applets will work at all without systemd. Last time I tried GNOME 3 it worked without any systemd components at all. It is already hard enough to imagine that we would have to ship packages without the appropriate dependencies on systemd; expecting them to have the same functional coverage without it is simply insane. There's no bloody way it's true, claiming anything like that is actually insanity. -- Cheers, Andrew signature.asc Description: PGP signature
Bug#727708: init system discussion status
Josh Triplett writes (Bug#727708: init system discussion status): I don't subscribe to debian-ctte@; I read it via the list archives. I've been replying using the Reply to: links at the bottom of mails, and then manually copying and quoting the responses. Those links reply to debian-c...@lists.debian.org, so unless I manually edit the destination (which I've done in a few cases where the destination was a bug report), it ends up going to the list. It'd be nice if those links paid attention to the To/Cc/Reply-To/Mail-Followup-To addresses, and otherwise acted like hitting the reply key in a mail client. I'd also add my voice to the set of people who have requested mbox archives in the past. mbox archives of bugs are available, if that's any use. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
On Sun, 05 Jan 2014 at 00:54:04 +, Dimitri John Ledkov wrote: post-208 rewrite, is interesting, burning bridges with dbus? As in all emails I write about this, I'm trying to be consistent about spelling the abstract specification D-Bus and its oddly-licensed reference implementation dbus. I am a D-Bus and dbus maintainer. libsystemd-bus is not, in itself, something that burns any bridges with traditional D-Bus. It's a reimplementation of dbus (D-Bus' reference implementation) under a less bizarre license[1] (and probably a nicer C API too), taking advantage of Linuxisms to be more concise and probably more correct (whereas dbus is portable, with all the usual costs of portability, like large chunks of #ifdef'd socket-wrangling code that haven't actually worked for several years). kdbus is a new, non-standardized, Linux-kernel-assisted transport for D-Bus, supported by libsystemd-bus and by unmerged branches of GDBus and dbus. I'm trying to make sure that it gets proper design/code review from experienced D-Bus (and dbus) developers, and is added to the D-Bus Specification. If you are interested in this, please join the D-Bus upstream mailing list/bug tracker (and if you see discussion elsewhere that should go to D-Bus' upstream locations, please direct it there). If I maintained systemd, I would personally not have merged any kdbus support into the master branch yet - I don't think it's ready for that - but systemd upstream have chosen to include it in a deactivated state. I'm not sure whether it's #ifdef'd out by default, or just not usable on unmodified kernels, but either way, systemd on current kernels (without either a patch or an out-of-tree module) doesn't and can't use it. Standardizing on a toolkit/ecosystem marshaling (GVariant), despite not being political, looks odd from cross-platform point of view. D-Bus' marshalling is sufficiently weird that I can understand why the kdbus developers want to use traditional D-Bus - kdbus as a flag day for switching to different marshalling - at the moment the plan seems to be to say traditional D-Bus over a socket always uses D-Bus 1.0 marshalling, kdbus always uses GVariant marshalling rather than making them orthogonal, to have fewer combinations that need to be tested. If GVariant's marshalling is better than D-Bus' (I haven't researched it myself, but I can well believe that it is), then it seems fine to use that, rather than inventing some third thing for the sake of neutrality. Does that also mean that projects linking against libdbus1 cannot talk to systemd components native, without compat translator running on the systemd side? At the moment: no, systemd still speaks the traditional D-Bus protocol via a socket to dbus-daemon. If/when kdbus is in the kernel and libsystemd-bus, but not dbus: yes, the plan seems to be that systemd will to provide a bridge that replaces dbus-daemon, for compatibility with current D-Bus implementations. If/when a kdbus transport is added to dbus too (one exists in a branch/fork, but has not been submitted upstream): no, libdbus1 (part of dbus) can use that transport. S [1] dbus is dual GPL/AFL and cannot be relicensed to (say) MIT or LGPL, because one significant early copyright holder has gone out of business and it isn't clear who owns that part of the copyright now -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
Russ Allbery r...@debian.org writes: My inclination would be to give maintainers technical advice to accept integrations with either existing synchronization protocols, but leave it as technical advice rather than the binding part of the decision. I strongly agree. Bdale pgp5ex_rCH3W3.pgp Description: PGP signature
Bug#727708: init system discussion status
On Fri, 2014-01-03 at 18:41 -0800, Russ Allbery wrote: 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. Essentially this boils down to whether the logind interfaces will be available when using sysvinit. Most of the other interfaces (at least for current gnome as in experimental) would cause some functionality to either be missing or not work, but wouldn't yield a completely unusable system. Not having the logind interface is a lot harder to cope with and something that will not only impact Gnome. So essentially the most likely impact of using sysvinit _without_ a provider of the logind interface would be a non-usable Gnome desktop (and potentially even GDM to be unusable) on Jessie systems. -- Sjoerd Simons sjo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
Bdale Garbee writes (Bug#727708: init system discussion status): Russ Allbery r...@debian.org writes: My inclination would be to give maintainers technical advice to accept integrations with either existing synchronization protocols, but leave it as technical advice rather than the binding part of the decision. I strongly agree. OK, I would be quite happy to say that we would like each daemon package to implement at least one non-forking startup protocol, but that we won't force this on maintainers. Would that suit you both ? Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
Uoti Urpala writes (Bug#727708: init system discussion status): There are two different kinds of dependencies: dependencies expressed in package metadata, and functional dependencies (as in whether the package does anything useful with another init). Your earlier wording sounds like it was talking about the former (installable) and Ian's proposal definitely was (explicitly mentioning package fields), but the fully working you use now sounds like it's about the latter. Thanks for pointing this out. My proposal is too weak in this respect. I intended to make the stronger statement. As the systemd-ui example shows, [...] I think systemd-ui is part of the systemd init system so falls into the exception. Of course that means that nothing else should depend (functionally or in package dependencies) on it. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
Le samedi 04 janvier 2014 à 12:47 +, Ian Jackson a écrit : Uoti Urpala writes (Bug#727708: init system discussion status): Your earlier wording sounds like it was talking about the former (installable) and Ian's proposal definitely was (explicitly mentioning package fields), but the fully working you use now sounds like it's about the latter. Thanks for pointing this out. My proposal is too weak in this respect. I intended to make the stronger statement. I think systemd-ui is part of the systemd init system so falls into the exception. Of course that means that nothing else should depend (functionally or in package dependencies) on it. There is no way that, for example, some of the GNOME control center applets will work at all without systemd. It is already hard enough to imagine that we would have to ship packages without the appropriate dependencies on systemd; expecting them to have the same functional coverage without it is simply insane. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
Ian Jackson ijack...@chiark.greenend.org.uk writes: Bdale Garbee writes (Bug#727708: init system discussion status): Russ Allbery r...@debian.org writes: My inclination would be to give maintainers technical advice to accept integrations with either existing synchronization protocols, but leave it as technical advice rather than the binding part of the decision. I strongly agree. OK, I would be quite happy to say that we would like each daemon package to implement at least one non-forking startup protocol, but that we won't force this on maintainers. Would that suit you both ? I may have lost the thread here, but that doesn't sound quite right. Wouldn't we want to say that each daemon package should implement the native non-forking startup protocol for the default init system, and we would like the maintainer to merge patches for other startup protocols if active maintainers of other init systems ask for this? -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
Russ Allbery writes (Bug#727708: init system discussion status): Ian Jackson ijack...@chiark.greenend.org.uk writes: Would that suit you both ? I may have lost the thread here, but that doesn't sound quite right. Wouldn't we want to say that each daemon package should implement the native non-forking startup protocol for the default init system, and we would like the maintainer to merge patches for other startup protocols if active maintainers of other init systems ask for this? It seems daft to go around making two (or perhaps three or more) patches to every daemon when one patch to each daemon, and a couple of compatibility modes in the init systems, would suffice. There is no technical reason why systemd can't support raise(SIGSTOP) and no technical reason why upstart can't support sd_notify. I hereby volunteer to implement support for sd_notify in upstart if it's chosen. It looks like it should take about an afternoon. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
Sjoerd Simons sjo...@debian.org writes: Essentially this boils down to whether the logind interfaces will be available when using sysvinit. Most of the other interfaces (at least for current gnome as in experimental) would cause some functionality to either be missing or not work, but wouldn't yield a completely unusable system. Thanks for that. That's one of the key pieces of information that I was wondering about, and I was just told I should probably talk to you since you'd know. :) Not having the logind interface is a lot harder to cope with and something that will not only impact Gnome. So essentially the most likely impact of using sysvinit _without_ a provider of the logind interface would be a non-usable Gnome desktop (and potentially even GDM to be unusable) on Jessie systems. If we go with systemd, I think we have three options: 1. Allow packages that require logind to depend on systemd and require that it be used as the init system. This is certainly the simplest for packaging applications that want to depend on logind, as well as for the systemd maintainers. However, it means we lose the ability for users of at least those packages to be able to fall back on sysvinit if something goes wrong with systemd on their systems. In the past, we've tried pretty hard to provide that capability when making a disruptive change of this kind. 2. Package logind separately from systemd, get it working with sysvinit. The problems with doing this, as I understand it, is that we'd not be able to upgrade such a separately-packaged logind beyond 204 for jessie. I'm not sure how much impact that would have. Also, it sounded to me like we would need to figure out who was going to do that work and maintain that package, including in the stable release. If the current systemd maintainers are not interested in doing this, we absolutely shouldn't try to force them to do so. Someone else would need to step forward to do this and figure out the right package relationships. (Also, it would be good to maintain this separately so that the systemd maintainers could move forward with newer versions of systemd, including the logind built from its source.) 3. Get GNOME working at some level without logind. I think it would be entirely acceptable for there to be some loss of functionality when GNOME is started in this way, such as no user switching and some configuration and control panels that rely on logind functionality not working. But it would need to at least start and be basically functional for this to be a meaningful option. None of these options are very appealing, but I think we have to pick one of them. I'm not seeing other options at the moment. I think option 3 would be the most appealing for the project as a whole, but I realize that's also the option that puts the most burden on GNOME maintainers. The only upside I can offer for that is that this would be in the context of moving forward with systemd and would be a one-release issue. Post jessie, you'd be able to move forward with a standard integration. It's worth noting that option 3 is also what would be required if we wanted to support GNOME on kFreeBSD. I'm not sure if anyone is working on that port or sufficiently interested in it to try to make it work, but there may be some additional resources there. Do you think there's a way that we could make option 3 work that the GNOME maintainers would be comfortable with? The systemd maintainers should definitely feel free to tell me if I'm misunderstanding their feelings on option 2. Do you think I should ask more generally on debian-devel if there are any other maintainers in Debian that anticipate any problem with either requiring sysvinit be supported as PID 1 for jessie, or with logind being an optional component for jessie? If we go with upstart as the default, obviously the situation is much different, possibly including multiple different maintenance teams, and would require packaging a broken-up version of systemd and building a maintenance team around that. It's basically option 2 with a bunch of added disruption. There are enough variables involved in that situation that I hesitate to guess what it would look like. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
Ian Jackson ijack...@chiark.greenend.org.uk writes: Russ Allbery writes (Bug#727708: init system discussion status): I may have lost the thread here, but that doesn't sound quite right. Wouldn't we want to say that each daemon package should implement the native non-forking startup protocol for the default init system, and we would like the maintainer to merge patches for other startup protocols if active maintainers of other init systems ask for this? It seems daft to go around making two (or perhaps three or more) patches to every daemon when one patch to each daemon, and a couple of compatibility modes in the init systems, would suffice. Okay, it's possible that we just disagree here. Having actually done it, I don't see any reason not to implement both the upstart and systemd readiness protocols in a typical daemon. It's not at all hard, and in most cases one is going to want to implement socket activation on the systemd side anyway, which makes the readiness protocol mostly irrelevant. Whether systemd upstream should support the SIGSTOP protocol is certainly debatable, but I'm very reluctant to support an option that tries to force the systemd maintainers to support the protocol indefinitely as a Debian-specific fork. This protocol is not widely used in Debian at the moment, nor is it widely used upstream, and I think it would be a far better use of our time to add support for the systemd protocol to upstart. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
Russ Allbery writes (Bug#727708: init system discussion status): Ian Jackson ijack...@chiark.greenend.org.uk writes: Are the protocols offered by systemd and upstart each so plainly reasonable, that we are willing to overrule a maintainer who feels they protocol they are asked to support is too ugly or burdensome ? Are such a maintainer's objections so unreasonable ? Ah, okay, I see what you're getting at. I think they are. Furthermore, I don't think there's any likely prospect that either will adopt a socket-based synchronization protocol other than systemd's, so saying that these aren't patches maintainers are required to take pretty much says that maintainers aren't required to integrate with the synchronization protocols. In practice I think, given the political context, almost every daemon maintainer (or upstream) will be willing to provide at least _one_ of current the upstart and systemd protocols. I don't see any value in insisting that every daemon maintainer should support both, perhaps against their will, when supporting both protocols in each of the perhaps six init systems will be much less work overall. We could do that. In general, I'd really prefer to defer to maintainers on what they're willing to integrate with. [...] So in that case you're saying you wouldn't want to overrule a maintainer who declined to provide either of the currently available protocols. Which seems to be the opposite of what you say above. My inclination would be to give maintainers technical advice to accept integrations with either existing synchronization protocols, but leave it as technical advice rather than the binding part of the decision. Of course formally all of this is just advisory, because no specific example is here yet. But I take you to mean that you don't want to signal that we would overrule maintainers in particular circumstances. Let us suppose that we don't say anything in particular about what maintainers are expected to do. (I'll also suppose WLOG that the TC collectively votes for upstart as default.) I would expect the following things to happen, then: upstart would get sd_notify support; an upstart contributor send a patch adding an upstart job for a daemon package which already supports systemd; the daemon maintainer rejects the patch; the upstart contributor refers the matter to us. If we signal now what we would think of such a situation then this will be less likely and if it does happen it will take much less long to resolve. (The same scenario might occur the other way round, although currently the systemd maintainers have rejected the proposal to support upstart's readiness protocol.) It also includes the important point that it is up to the maintainer to justify non-inclusion, not the other way around. I guess the question here is how many conflicts we anticipate and whether it's worth being somewhat confrontational ourselves to head it off. If there aren't conflicts in practice, we're just creating conflict without a need. I don't think it matters a tremendous amount, though. It is always easier and less personal to have these conversations in the abstract, before particular people have got upset about the specific question. I really think we should decide in advance some ground rules for what we would and would not be willing to force on a maintainer. I don't agree. Unless we either have a compatibility shim, or a policy decision to transition, every package ought to be required to provide something in the Debian menus. Isn't this situation analogous to the mime-support argument where we required a package to reinstate a mime entry ? Sorry, I didn't state my objection very well. I wasn't talking about packages removing menu files. Rather, your original wording to me sounds like introducing support for desktop files in Debian would violate this guidance unless the one introducing that support went through the Policy process first, even if the new support did not conflict with menus and did not break anything about menus. That seems wrong. Perhaps my wording needs improving. The problematic step is not the introduction of a parallel system. The problematic steps are: * Stopping providing menu files in existing menu entry providers * Existing menu consumers stopping offering a way in the UI to access the Debian menu system menu * Justifying the above two steps on the grounds that menu is obsolete All of these have happened, without a proper consideration of (a) the goals of _all_ the users and admins who rely on or use the Debian menu and how those goals can be met with the new arrangements and (b) a proper transition plan. No matter how creaky and obsolete the Debian menu system is (or is thought to be in some quarters), that's not the way to go about things. It causes significant technical problems, and it's also very rude. We have unfortunately seen this same pattern more than once
Bug#727708: init system discussion status
Russ Allbery writes (Bug#727708: init system discussion status): Ian Jackson ijack...@chiark.greenend.org.uk writes: 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. Personally I think leaving this in makes the resolution look surreal and out of touch. But, anyway, we can focus on the upstart position first and deal with that later. OK. 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. Right. I looked at the reverse-dependencies of sysvinit in sid and didn't see anything untoward. 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). OK. But I will hold off editing 6C for this as we seem to be moving in a different direction. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
(Josh, is there some reason why you replied to the TC list directly rather than the bug report ? You should send your messages to the bug so they are filed, displayed and archived there. Thanks.) Josh Triplett writes (Re: Bug#727708: init system discussion status): Clint Adams wrote: 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. Thanks for your intervention which is helpful. 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), Right. *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, Personally I think this is a pretty nasty way for the git packages to have done things, although I understand why. But, regardless, I think it's certainly fine from the init system compatibility point of view. ... (Note that the latter would work better if upstart stopped conflicting with sysvinit, similar to how systemd can be installed without being init.) There does seem to need to be some work there. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
Ian Jackson writes (Re: Bug#727708: init system discussion status): Are you going to vote to overrule a maintainer who says I have already implemented non-forking readiness protocol X and I think support for all init systems in my daemon should be done via one protocol. Please do send me a patch for your init system Y task file (and correponding packaging support) when init system Y has support for protocol X. ? ISTM that if this situation arises it is due to a failure by the init system to be sufficiently accomodating. I would vote to not overrule a maintainer in such a situation. This might prompt of course the question of whether I would vote to overrule the init system maintainer. If it were the default init system, certainly. But I would not want to have the default init system be one where this was going to be necessary. The response from the upstart maintainers to the request to support the systemd socket activation protocol convinces me this isn't a problem for upstart. We know it is a problem with systemd. For a non-default init system it seems to me that this is a decision for that init system's community. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
Ian Jackson ijack...@chiark.greenend.org.uk writes: Russ Allbery writes (Bug#727708: init system discussion status): I think they are. Furthermore, I don't think there's any likely prospect that either will adopt a socket-based synchronization protocol other than systemd's, so saying that these aren't patches maintainers are required to take pretty much says that maintainers aren't required to integrate with the synchronization protocols. In practice I think, given the political context, almost every daemon maintainer (or upstream) will be willing to provide at least _one_ of current the upstart and systemd protocols. I don't see any value in insisting that every daemon maintainer should support both, perhaps against their will, when supporting both protocols in each of the perhaps six init systems will be much less work overall. We could do that. In general, I'd really prefer to defer to maintainers on what they're willing to integrate with. [...] So in that case you're saying you wouldn't want to overrule a maintainer who declined to provide either of the currently available protocols. Which seems to be the opposite of what you say above. Yes, I know, I'm being confusing. I'm sorry about that. It's because I'm trying to balance two different goals, which are in conflict here. One is that I prefer to defer to maintainers on how to maintain their own packages. The other is that I think we all have some obligation to let other people work on things they care about if it doesn't cause disruptive impact on us. I think the wording path that you're going down right now requires us to take a firm stand one way or another, in advance, on what we're going to tell the whole project to do. I consider telling people what to do to be an inherent problem, although sometimes an unavoidable one. The more I think about this, the more I prefer to give maintainers the technical advice that they should integrate with any init system that is being actively developed, provided that it doesn't have a negative impact on their package, and leave it at that. If we have to decide whether to override a maintainer on whether to support a non-default init system, well, we'll have to decide that, and it will be unpleasant. But I'm not sure we need to proactively dive into that unpleasantness. Of course formally all of this is just advisory, because no specific example is here yet. But I take you to mean that you don't want to signal that we would overrule maintainers in particular circumstances. Right. Let us suppose that we don't say anything in particular about what maintainers are expected to do. (I'll also suppose WLOG that the TC collectively votes for upstart as default.) I would expect the following things to happen, then: upstart would get sd_notify support; an upstart contributor send a patch adding an upstart job for a daemon package which already supports systemd; the daemon maintainer rejects the patch; the upstart contributor refers the matter to us. I'm not sure why you think the daemon maintainer rejects the patch part of this is likely, particularly if upstart supports sd_notify, which makes the patch basically trivial. I don't think this is a likely conflict. A much more likely conflict would be that upstart is adopted as the default init system, a daemon is patched to support raise(SIGSTOP), a systemd contributor submits a patch to support sd_notify (or socket activation), and the daemon maintainer rejects that patch. I personally think that such a patch should be accepted. But I don't know that I'm willing to say in advance that we're going to try to force that patch to be accepted. So I'm good with offering technical advice to accept such patches, but not with signaling that we're going to override people who don't. It is always easier and less personal to have these conversations in the abstract, before particular people have got upset about the specific question. I really think we should decide in advance some ground rules for what we would and would not be willing to force on a maintainer. I consider the TC, when working properly, to be like a court, not an executive or legislature. I therefore prefer focused and limited decisions for the same reasons that court decisions try to err on the side of being focused and limited. That doesn't completely rule out your point, of course; courts, particularly high courts, set these sorts of guidelines for evaluating future cases all the time. But I'm not seeing it as obviously necessary here. No matter how creaky and obsolete the Debian menu system is (or is thought to be in some quarters), that's not the way to go about things. It causes significant technical problems, and it's also very rude. I would be more comfortable with this argument if we had a working Policy process that could reach these conclusions in a timely fashion. It's been obvious to me that desktop files are a better (and, more
Bug#727708: init system discussion status
Russ Allbery writes (Bug#727708: init system discussion status): Ian Jackson ijack...@chiark.greenend.org.uk writes: It seems daft to go around making two (or perhaps three or more) patches to every daemon when one patch to each daemon, and a couple of compatibility modes in the init systems, would suffice. Okay, it's possible that we just disagree here. Having actually done it, I don't see any reason not to implement both the upstart and systemd readiness protocols in a typical daemon. It's not at all hard, and in most cases one is going to want to implement socket activation on the systemd side anyway, which makes the readiness protocol mostly irrelevant. The question isn't what you would prefer. The question is this: Are you going to vote to overrule a maintainer who says I have already implemented non-forking readiness protocol X and I think support for all init systems in my daemon should be done via one protocol. Please do send me a patch for your init system Y task file (and correponding packaging support) when init system Y has support for protocol X. ? ISTM that if this situation arises it is due to a failure by the init system to be sufficiently accomodating. I would vote to not overrule a maintainer in such a situation. Whether systemd upstream should support the SIGSTOP protocol is certainly debatable, but I'm very reluctant to support an option that tries to force the systemd maintainers to support the protocol indefinitely as a Debian-specific fork. We have endless Debian-specific patches which are precisely there to support additional protools which make packaging and integration easier. OK, nowadays there is less need of this because our technical choices have been more widely recognised as good, but it is not something we should be afraid of. Support for raise(SIGSTOP) would be a small patch which Debian could easily carry indefinitely if need be. Consider for example the support for searching whatever.d directories for configuration of one kind or another, which has been added by many Debian maintainers first in their patches (and I bet there are packages where that's still not upstream). This protocol is not widely used in Debian at the moment, nor is it widely used upstream, and I think it would be a far better use of our time to add support for the systemd protocol to upstart. I think we need to add both protocols to both daemons. This is because I want integration to be as easy and uncontroversial as possible. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
Ian Jackson ijack...@chiark.greenend.org.uk writes: Russ Allbery writes (Bug#727708: init system discussion status): Whether systemd upstream should support the SIGSTOP protocol is certainly debatable, but I'm very reluctant to support an option that tries to force the systemd maintainers to support the protocol indefinitely as a Debian-specific fork. We have endless Debian-specific patches which are precisely there to support additional protools which make packaging and integration easier. OK, nowadays there is less need of this because our technical choices have been more widely recognised as good, but it is not something we should be afraid of. I'm doubtful that either of us are going to convince the other on this point. I don't consider it comparable to the other examples you're citing, and I think it's inobvious that raise(SIGSTOP) is a good technical choice. Simple, yes, but that's not the same thing. Anyway, it's not at all clear to me that we need to argue about this here. If we adopt upstart, and a bunch of daemons are adapted to SIGSTOP, that's obviously going to increase the utility of supporting SIGSTOP in systemd. I would rather let the systemd maintainers discuss that situation with upstream and reach their own conclusions given the dynamics of that situation, which are difficult to predict in advance. If we adopt systemd, then I think it's fairly uncontroversial to ask maintainers to adopt support for systemd's socket activation or, failing that, notification protocol. So, either way, I don't see the utility of making this kind of statement now. I think we need to add both protocols to both daemons. This is because I want integration to be as easy and uncontroversial as possible. This is the sort of statement that carries one meaning when stated as a personal opinion as an individual Debian contributor, and a completely different meaning when included in a TC decision. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
Ian Jackson ijack...@chiark.greenend.org.uk writes: The question isn't what you would prefer. The question is this: Are you going to vote to overrule a maintainer who says I have already implemented non-forking readiness protocol X and I think support for all init systems in my daemon should be done via one protocol. Please do send me a patch for your init system Y task file (and correponding packaging support) when init system Y has support for protocol X. ? ISTM that if this situation arises it is due to a failure by the init system to be sufficiently accomodating. I would vote to not overrule a maintainer in such a situation. I would rather not state an opinion on this at the moment, since I think it's a difficult decision and will depend on the exact situation in Debian at the time, the importance of the package, the disruption that might be caused by it not supporting a different init system, and so forth. It's also going to matter quite a lot whether the one readiness protocol that they implemented is one that's supported by the default init system, and whether it's one supported by the init system used by the non-Linux ports. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
Russ Allbery writes (Bug#727708: init system discussion status): I consider the TC, when working properly, to be like a court, not an executive or legislature. One of our roles is to rule on the content of policy. That's much more like a legislative role. I think we should see what the other TC members think. No matter how creaky and obsolete the Debian menu system is (or is thought to be in some quarters), that's not the way to go about things. It causes significant technical problems, and it's also very rude. I would be more comfortable with this argument if we had a working Policy process that could reach these conclusions in a timely fashion. It's been obvious to me that desktop files are a better (and, more importantly, more widely supported) representation of this information for over six years now, but given that I, as a Policy Editor, don't know how to effectively get there from here, I have a hard time blaming the GNOME and KDE maintainers for not knowing either. The TC has been more-or-less functional for some time. If the policy process is not fit for purpose, or gets wedged due to lack of consensus, or whatever, then the TC is the place where that can be worked around. The old excuse that our governance processes don't work is, I think, no longer available in that case. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
On 4 January 2014 15:46, Josselin Mouette j...@debian.org wrote: Le samedi 04 janvier 2014 à 12:47 +, Ian Jackson a écrit : Uoti Urpala writes (Bug#727708: init system discussion status): Your earlier wording sounds like it was talking about the former (installable) and Ian's proposal definitely was (explicitly mentioning package fields), but the fully working you use now sounds like it's about the latter. Thanks for pointing this out. My proposal is too weak in this respect. I intended to make the stronger statement. I think systemd-ui is part of the systemd init system so falls into the exception. Of course that means that nothing else should depend (functionally or in package dependencies) on it. There is no way that, for example, some of the GNOME control center applets will work at all without systemd. It is already hard enough to imagine that we would have to ship packages without the appropriate dependencies on systemd; expecting them to have the same functional coverage without it is simply insane. Can you please explain how a user-level application is dependent on the system (root) init daemon be systemd-init? Especially since it's expected to have sysvinit fully functional in Jessie. Or is this to do with other, inferior to those currently in debian, ways of e.g. setting up system-wide locales? Or does it depend on other APIs, which have multiple alternative providers, e.g. systemd-logind. With a decision for systemd, are we by transitive means[1] mandating usage of all other daemons present in the systemd source package and overruling maintainers of existing functionality with alternative or compatible APIs[2]? If we are choosing, non-standartised systemd APIs[3], surely it should be done as a runtime detection, rather than packaging level dependency. Because there are multiple providers of the same APIs, possible at different compatibility levels of systemd versioning and until upgraded system is rebooted, only some implementations can start and be already running. Although not supported officially, I do like that stable can typically be fully functional since the dist-upgrade. Also it is sad that systemd upstream is actively promoting for everyone to execute runtime checks of is systemd-init pid1, and what's systemd version number, granted Martin Pitt did identify this problem and fixed majority of opensource projects to check for the requested/required functionality, instead of arbitrary transitive checks of pid1. This in part enables to run systemd-logind without systemd-init as pid 1. Also which upstream are staying with? systemd upstream git history[4] has only one branch, which is linear with linear version number increments, without any stable release branches or other indications of which patches are stable (or possibly security) bugfixes. Fedora 19 appears to be packaging patches from v204-stable branch which I can't find anywhere public. Thankfully it's not a single giant patch as it's done by RedHat for their kernels, but actually git am formatted series of 116 patches[5]. The diffstat between: - debian package and git v204 checkout is: 44 files, 246 +, 566 - - fedora 19-204 and v204 tarball: 102 files, 11368 +, 1366 - - rhel 7-beta-src-iso and v207 tarball: 133 files changed, 2364 insertions(+), 1686 deletions(-) Which is a significant chunk of fixes. Looking at some of them, they are true gems like don't truncate and loose multiline syslog messages which is not fixed in Debian at the moment. Can we please not have journald by default in jessie, cause I don't want my syslog truncated?! In my opinion it is unwise to ship something into stable, ahead of upstream doing so for their support customers (RedHat Enterprise Linux). We've had a charming history of doing so with pulseaudio: with default in 2007 in Fedora, shipped in stable Ubuntu 8.04 LTS in 2008, where Lennart promote it as stable to Ubuntu Developers at first, and later claiming that Ubuntu didn't exactly do a stellar job. They didn't do their homework. Redhat enterprice linux has shipped it version 6 - in 2011 it seems. Pulseaudio did turn out ok, although years later, after extensive usage by real customers base (unfortunately Ubuntu customers first, and later RedHat's). Fedora/RPM based distributions are significantly different, thus it is inevitable that we'll have to maintain a fork of systemd for best integration into Debian. This does not seem evident from the current systemd maintainers, which file bugs to disable/remove/override debian functionality and components with inferior systemd counterparts. Now the questions is, what will RHELv7 ship? is it v204, v204-stable (non-public git), v207-stable (non-public git), v208, v208-stable (non-public git)? And what level of systemd is targetted to be integrated into jessie? At the moment RHEL beta 7 has systemd-207 with 95 long patch series. This looks to me as in-flux state. How is systemd stable maintenance going to be handled
Bug#727708: init system discussion status
On Fri, Jan 03, 2014 at 04:40:54PM -0800, Russ Allbery wrote: 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. If it's horribly unlikely for jessie, then it doesn't seem to me like something that the TC should be telling porters they should do. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#727708: init system discussion status
Steve Langasek vor...@debian.org writes: On Fri, Jan 03, 2014 at 04:40:54PM -0800, Russ Allbery wrote: 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. If it's horribly unlikely for jessie, then it doesn't seem to me like something that the TC should be telling porters they should do. I thought that was already resolved? I objected to the should in the original language regarldess of which init system we choose, and Ian said that he'd reworded it already to something akin to mine, which just says that ports will use the same default init system if it has been ported, otherwise yadda yadda. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
On Sat, Jan 04, 2014 at 06:14:30PM +, Ian Jackson wrote: ... (Note that the latter would work better if upstart stopped conflicting with sysvinit, similar to how systemd can be installed without being init.) There does seem to need to be some work there. That has already been resolved in unstable, with the split of sysvinit contents out of the Essential: yes sysvinit into sysvinit-core. (A necessary precondition for switching to either systemd-sysv or upstart for jessie.) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#727708: init system discussion status
]] Russ Allbery 2. Package logind separately from systemd, get it working with sysvinit. The problems with doing this, as I understand it, is that we'd not be able to upgrade such a separately-packaged logind beyond 204 for jessie. I'm not sure how much impact that would have. Also, it sounded to me like we would need to figure out who was going to do that work and maintain that package, including in the stable release. If the current systemd maintainers are not interested in doing this, we absolutely shouldn't try to force them to do so. Someone else would need to step forward to do this and figure out the right package relationships. (Also, it would be good to maintain this separately so that the systemd maintainers could move forward with newer versions of systemd, including the logind built from its source.) [...] The systemd maintainers should definitely feel free to tell me if I'm misunderstanding their feelings on option 2. You are not. I'd like to expand slightly that I'd be ok with having it part of the systemd package as long as somebody shows up and commits to maintaining that functionality long-term and with the explicit understanding of the TC that if the necessary manpower to do that work disappears we will not be holding to rest of the init system back. It might be that packaging up logind completely separately by such a person (or team) might be a better approach (as you suggest). -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
Russ Allbery writes (Bug#727708: init system discussion status): I thought that was already resolved? I objected to the should in the original language regarldess of which init system we choose, and Ian said that he'd reworded it already to something akin to mine, which just says that ports will use the same default init system if it has been ported, otherwise yadda yadda. I nicked your wording. Mutatis mutandi, it would say: 2. The default init(1) in jessie for non-Linux ports will be systemd if it has been ported and confirmed by the porters to be working by the time of the jessie release. Failing this, the default init(1) in jessie for non-Linux ports is left to the discretion of the maintainers of that port. [ However, the Technical Committee requests that, should systemd be unavailable on both Hurd and kFreeBSD, the Hurd and kFreeBSD porters agree on a single alternative init(1) implementation that will be shared by both ports. ] [ Non-use of systemd should not be a criterion for architecture qualification status in jessie. ] I think this is a daft thing to say. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
On Sat, Jan 04, 2014 at 11:08:36AM -0800, Russ Allbery wrote: Steve Langasek vor...@debian.org writes: On Fri, Jan 03, 2014 at 04:40:54PM -0800, Russ Allbery wrote: 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. If it's horribly unlikely for jessie, then it doesn't seem to me like something that the TC should be telling porters they should do. I thought that was already resolved? I objected to the should in the original language regarldess of which init system we choose, and Ian said that he'd reworded it already to something akin to mine, which just says that ports will use the same default init system if it has been ported, otherwise yadda yadda. Ah - sorry, I apparently missed that. On Sat, Jan 04, 2014 at 07:28:56PM +, Ian Jackson wrote: I nicked your wording. Mutatis mutandi, it would say: 2. The default init(1) in jessie for non-Linux ports will be systemd if it has been ported and confirmed by the porters to be working by the time of the jessie release. Failing this, the default init(1) in jessie for non-Linux ports is left to the discretion of the maintainers of that port. [ However, the Technical Committee requests that, should systemd be unavailable on both Hurd and kFreeBSD, the Hurd and kFreeBSD porters agree on a single alternative init(1) implementation that will be shared by both ports. ] [ Non-use of systemd should not be a criterion for architecture qualification status in jessie. ] I think this is a daft thing to say. I don't have a problem with this version of the wording, with the should removed. While I think a systemd port is highly unlikely, I don't think it hurts anything for the TC to express a preference for all ports to be on the same page. The probability of this *happening* for a particular option will influence my vote, but I think it's a sound technical recommendation regardless. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#727708: init system discussion status
]] Dimitri John Ledkov Also which upstream are staying with? systemd upstream git history[4] has only one branch, which is linear with linear version number increments, without any stable release branches or other indications of which patches are stable (or possibly security) bugfixes. That's generally communicated in the release announcements as well as on the systemd-devel mailing list. Fedora 19 appears to be packaging patches from v204-stable branch which I can't find anywhere public. Thankfully it's not a single giant patch as it's done by RedHat for their kernels, but actually git am formatted series of 116 patches[5]. Were you unable to find http://pkgs.fedoraproject.org/cgit/systemd.git/log/?h=f19 ? It's where Fedora has all of their packaging.. Fedora/RPM based distributions are significantly different, thus it is inevitable that we'll have to maintain a fork of systemd for best integration into Debian. This does not seem evident from the current systemd maintainers, which file bugs to disable/remove/override debian functionality and components with inferior systemd counterparts. Can you provide bug numbers for those allegations, please? [4] it appears that upstream git is used as packaging basis, instead of the tarball which has pre-generated documentation and loads of other files. If you here are talking about the systemd packaging, it seems you've misunderstood something. What are you missing in the source package? -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
On Sat, Jan 04, 2014 at 06:14:30PM +, Ian Jackson wrote: (Josh, is there some reason why you replied to the TC list directly rather than the bug report ? You should send your messages to the bug so they are filed, displayed and archived there. Thanks.) I don't subscribe to debian-ctte@; I read it via the list archives. I've been replying using the Reply to: links at the bottom of mails, and then manually copying and quoting the responses. Those links reply to debian-c...@lists.debian.org, so unless I manually edit the destination (which I've done in a few cases where the destination was a bug report), it ends up going to the list. It'd be nice if those links paid attention to the To/Cc/Reply-To/Mail-Followup-To addresses, and otherwise acted like hitting the reply key in a mail client. I'd also add my voice to the set of people who have requested mbox archives in the past. Josh Triplett writes (Re: Bug#727708: init system discussion status): Clint Adams wrote: 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. Thanks for your intervention which is helpful. 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), Right. *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, Personally I think this is a pretty nasty way for the git packages to have done things, although I understand why. But, regardless, I think it's certainly fine from the init system compatibility point of view. I'm not a big fan of its long insistence on runit (git-daemon-sysvinit came much later), but I actually rather like the idea of putting init scripts and systemdiwde configuration in a separate package from daemons. In the case of git, it makes sense because the daemon lives in the git package, which shouldn't start a daemon. More generally, though, I wish more packages were split the way Apache is, with one package containing the daemon and all supporting files, and the other package containing the configuration for a systemwide daemon. I've found that particularly useful on many occasions. ... (Note that the latter would work better if upstart stopped conflicting with sysvinit, similar to how systemd can be installed without being init.) There does seem to need to be some work there. As I understand it, conflicting with sysvinit and not offering a package that can be installed in parallel with it was an intentional decision on the upstart maintainers' parts. - Josh Triplett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
On Sat, Jan 04, 2014 at 11:27:26AM -0800, Steve Langasek wrote: On Sat, Jan 04, 2014 at 06:14:30PM +, Ian Jackson wrote: ... (Note that the latter would work better if upstart stopped conflicting with sysvinit, similar to how systemd can be installed without being init.) There does seem to need to be some work there. That has already been resolved in unstable, with the split of sysvinit contents out of the Essential: yes sysvinit into sysvinit-core. (A necessary precondition for switching to either systemd-sysv or upstart for jessie.) That solves one part of the problem, in that the package upstart conflicts with is no longer Essential; however, that still doesn't allow installing upstart without making it /sbin/init. A split similar to the one between systemd and systemd-sysv would make that possible, allowing users to try out upstart by setting init= on the kernel command line, and allowing packages to use upstart for purposes other than running it as init (for instance, for graphical session startup). - Josh Triplett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
On Sat, 2014-01-04 at 09:56 -0800, Russ Allbery wrote: Sjoerd Simons sjo...@debian.org writes: Not having the logind interface is a lot harder to cope with and something that will not only impact Gnome. So essentially the most likely impact of using sysvinit _without_ a provider of the logind interface would be a non-usable Gnome desktop (and potentially even GDM to be unusable) on Jessie systems. If we go with systemd, I think we have three options: 1. Allow packages that require logind to depend on systemd and require that it be used as the init system. This is certainly the simplest for packaging applications that want to depend on logind, as well as for the systemd maintainers. However, it means we lose the ability for users of at least those packages to be able to fall back on sysvinit if something goes wrong with systemd on their systems. In the past, we've tried pretty hard to provide that capability when making a disruptive change of this kind. This one feels like a bit of a cost/benefit analysis to me. Is it worth it to force all packages to work properly (for some definition of properly) on a sysvinit system even in cases where this is a non-trivial amount of work? For e.g. daemon packages where this typically is a matter of keeping/writing an init script the cost is obviously very low, so probably worth it. For something like Gnome, it's a lot less obvious in my opinion. 2. Package logind separately from systemd, get it working with sysvinit. The problems with doing this, as I understand it, is that we'd not be able to upgrade such a separately-packaged logind beyond 204 for jessie. I'm not sure how much impact that would have. Also, it sounded to me like we would need to figure out who was going to do that work and maintain that package, including in the stable release. If the current systemd maintainers are not interested in doing this, we absolutely shouldn't try to force them to do so. Someone else would need to step forward to do this and figure out the right package relationships. (Also, it would be good to maintain this separately so that the systemd maintainers could move forward with newer versions of systemd, including the logind built from its source.) 3. Get GNOME working at some level without logind. I think it would be entirely acceptable for there to be some loss of functionality when GNOME is started in this way, such as no user switching and some configuration and control panels that rely on logind functionality not working. But it would need to at least start and be basically functional for this to be a meaningful option. The problem with this option is how to define some level and basically functional.. If it's enough to be able to login, launch some applications and have some basic window manager functionality that's probably possible. However some functionality which I would find pretty basic, e.g. configuring the network, suspending the machine, locking the screen might not be available. Also, would basic functionality mean that if things fail they fail gracefully? Given modern Gnome essentially doesn't get tested in a non-systemd environment anymore I'm sure there a lots of rough edges around. None of these options are very appealing, but I think we have to pick one of them. I'm not seeing other options at the moment. I think option 3 would be the most appealing for the project as a whole, but I realize that's also the option that puts the most burden on GNOME maintainers. The only upside I can offer for that is that this would be in the context of moving forward with systemd and would be a one-release issue. Post jessie, you'd be able to move forward with a standard integration. It's worth noting that option 3 is also what would be required if we wanted to support GNOME on kFreeBSD. I'm not sure if anyone is working on that port or sufficiently interested in it to try to make it work, but there may be some additional resources there. Actually for the project as a whole and for porting to KFreeBSD i would find option 2 more appealing as a starting point. logind is not just used by GNOME, so doing so is more generally useful. Especially for KFreeBSD as it lowers the barrier for entry for all logind users. Do you think there's a way that we could make option 3 work that the GNOME maintainers would be comfortable with? Do you think there is a way you can find someone willing to do the work? :).. The problem with both 2 and 3 is that it's work that needs to be done and maintained at least until Jessie is released. Which is work that as far as I'm aware nobody in the current Gnome team is motivated to do. So unless someone volunteers to take up the challenge to do the required work (and succeeds in doing so!), to me the options of what to do for Gnome in Jessie are: 0) Provide the user with a massively degraded
Bug#727708: init system discussion status
On Sat, Jan 04, 2014 at 06:59:46PM +, Dimitri John Ledkov wrote: Also it is sad that systemd upstream is actively promoting for everyone to execute runtime checks of is systemd-init pid1,... This is done public systemd libraries to become NOPs if not running on or not compiled for systemd, to make it easier to integrate systemd-related functionality in programs portable to other environments. Full original functionality can be always trivially restored. Built-in systemd components do no such checks, and generally are written with the assumption that they are using the same systemd versions. (What I'm saying is quite inprecise, but because it's not the main point, I don't want to go into details.) what's systemd version number, I'm not aware of any such checks. granted Martin Pitt did identify this problem and fixed majority of opensource projects to check for the requested/required functionality, instead of arbitrary transitive checks of pid1. This in part enables to run systemd-logind without systemd-init as pid 1. Also which upstream are staying with? systemd upstream git history[4] has only one branch, which is linear with linear version number increments, without any stable release branches or other indications of which patches are stable (or possibly security) bugfixes. git notes are used to mark backport-worthy commits. See http://lists.freedesktop.org/archives/systemd-devel/2013-September/013188.html. We currently mark patches as bugfixes (which includes fixes for bugs present in the latest release, but not those introduced later), or documentation and performance improvements. Fedora 19 appears to be packaging patches from v204-stable branch which I can't find anywhere public. It's my private branch I generate Fedora packages from [1]. It's the same content as in Fedora git repos [2], but in a more convenient form for me. I talked with other systemd maintainers in Fedora about making it more official and public, but we haven't found the time to do it yet. If it was to be useful to other people, it can certainly be done. [1] http://kawka.in.waw.pl/git/systemd/ [2] http://cgit.freedesktop.org/systemd/systemd/ Thankfully it's not a single giant patch as it's done by RedHat for their kernels, but actually git am formatted series of 116 patches[5]. The diffstat between: - debian package and git v204 checkout is: 44 files, 246 +, 566 - - fedora 19-204 and v204 tarball: 102 files, 11368 +, 1366 - - rhel 7-beta-src-iso and v207 tarball: 133 files changed, 2364 insertions(+), 1686 deletions(-) Which is a significant chunk of fixes. Looking at some of them, they are true gems like don't truncate and loose multiline syslog messages which is not fixed in Debian at the moment. Can we please not have journald by default in jessie, cause I don't want my syslog truncated?! In my opinion it is unwise to ship something into stable, ahead of upstream doing so for their support customers (RedHat Enterprise Linux). I think you're overestimating the (direct) influence of Redhat on system upstream bug fixes. There are patches (don't truncate and loose multiline... being one of them) done as a result of a bug reported in RHEL, but their number is insignificant compared to the number of bugs reported and fixed in Fedora, the upstream bugtracker and other distro's bugtrackers. Actually Debian is suffering here becuase of the large version gap to current upstream. It makes it much harder to reproduce bugs, and if fixes are done, additional work is required in backporting. After various codebase cleanups and the the post-208 rewrite to use libsystemd-bus in systemd components, any patch which touch dbus codepaths has to be rewritten rather than cherry-picked to such old versions. Zbyszek -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
Uoti Urpala uoti.urp...@pp1.inet.fi writes: On Fri, 2014-01-03 at 20:26 -0800, Nikolaus Rath wrote: Clint Adams cl...@debian.org writes: On Fri, Jan 03, 2014 at 10:02:01AM -0800, Nikolaus Rath wrote: 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. There are two different kinds of dependencies: dependencies expressed in package metadata, and functional dependencies (as in whether the package does anything useful with another init). Your earlier wording sounds like it was talking about the former (installable) and Ian's proposal definitely was (explicitly mentioning package fields), but the fully working you use now sounds like it's about the latter. I think that if a program functionally depends on another, but the package does not declare this dependency, then it's a bug. So in this context I consider functional dependencies and package dependencies to be the same. 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
On 4 January 2014 23:16, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Sat, Jan 04, 2014 at 06:59:46PM +, Dimitri John Ledkov wrote: Also it is sad that systemd upstream is actively promoting for everyone to execute runtime checks of is systemd-init pid1,... This is done public systemd libraries to become NOPs if not running on or not compiled for systemd, to make it easier to integrate systemd-related functionality in programs portable to other environments. Full original functionality can be always trivially restored. Built-in systemd components do no such checks, and generally are written with the assumption that they are using the same systemd versions. (What I'm saying is quite inprecise, but because it's not the main point, I don't want to go into details.) So components inside systemd-source tree do not follow what's advised to all other projects: e.g. link or statically include sd_* helper files, and perform runtime checks? How much functionality / api is exported by libraries/dbus of systemd to move components out of the systemd tree and into separate projects. Or, what's more interesting, projects external to systemd integrating on the same level. E.g. in upstart, all common code is factored into stable-api/abi libnih, which is then free to use by anyone (e.g. event bridges, mount helpers, etc.) and all communication to/from upstart is exported via dbus IPC (on private socket or systemd dbus). If code-sharing is only happening by being part of the systemd codebase, that also increases barrier of entry. E.g. it would be benefitial for systemd to support hallyn's cgroupmanager (which can be used standalone or not). what's systemd version number, I'm not aware of any such checks. I'll find references, but I believe some components in KDE starting doing so upstream which has been reported to me from ProjectNeon/Kubuntu. I'll follow up more on that. Again, not sure if this is lack or shared library for logind support, but a lot of projects were using sd_booted() (pid1 init check) instead of checking for logind e.g. (access(/run/systemd/seats/, F_OK) = 0) It would be easier if software that integrates with individual services was doing imperical checks of the services it uses, or better gracefully fail-over at runtime if those fail (e.g. over dbus). Also logind seat management seems to use systemd names instead of XDG-names (as done in other places) or like a generic name logind. Looks untidy, and making DEs claim they support or require systemd-init, when infact they mean logind. granted Martin Pitt did identify this problem and fixed majority of opensource projects to check for the requested/required functionality, instead of arbitrary transitive checks of pid1. This in part enables to run systemd-logind without systemd-init as pid 1. Also which upstream are staying with? systemd upstream git history[4] has only one branch, which is linear with linear version number increments, without any stable release branches or other indications of which patches are stable (or possibly security) bugfixes. git notes are used to mark backport-worthy commits. See http://lists.freedesktop.org/archives/systemd-devel/2013-September/013188.html. We currently mark patches as bugfixes (which includes fixes for bugs present in the latest release, but not those introduced later), or documentation and performance improvements. Thank you for this link, I was not aware of this policy. This is the first time i see git-notes used for tracking bugs needed for stable/security/documentation, and it was hard for me to find. Does also mean such stable maintenance only started in September 2013? Or some other scheme used before that? Current debian version of systemd is v204, tagged in May 2013. Fedora 19 appears to be packaging patches from v204-stable branch which I can't find anywhere public. It's my private branch I generate Fedora packages from [1]. It's the same content as in Fedora git repos [2], but in a more convenient form for me. I talked with other systemd maintainers in Fedora about making it more official and public, but we haven't found the time to do it yet. If it was to be useful to other people, it can certainly be done. Thank you for pointing out where it is. Maybe add a URL in the spec file pointing to where it is? Cause I've search hard and didn't manage to find where it's maintained. (or push a mirror to github systemd projects or some other place if you require team commit access) I guess that also makes the RHEL patch series based on yours/fedora releases. Are there changes that are in RHEL7 and not in fedora, your fork, and upstream? Debian SytemD maintainers, has the ~116 fedora's stable fixes patch series been reviewed and decided to not be applied? What about stable branches from other distributions, have those been investigated? [1] http://kawka.in.waw.pl/git/systemd/ [2] http://cgit.freedesktop.org/systemd/systemd/ Thankfully it's not
Bug#727708: init system discussion status
On 5 January 2014 00:07, Nikolaus Rath nikol...@rath.org wrote: Uoti Urpala uoti.urp...@pp1.inet.fi writes: On Fri, 2014-01-03 at 20:26 -0800, Nikolaus Rath wrote: Clint Adams cl...@debian.org writes: On Fri, Jan 03, 2014 at 10:02:01AM -0800, Nikolaus Rath wrote: 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. There are two different kinds of dependencies: dependencies expressed in package metadata, and functional dependencies (as in whether the package does anything useful with another init). Your earlier wording sounds like it was talking about the former (installable) and Ian's proposal definitely was (explicitly mentioning package fields), but the fully working you use now sounds like it's about the latter. I think that if a program functionally depends on another, but the package does not declare this dependency, then it's a bug. So in this context I consider functional dependencies and package dependencies to be the same. Whilst generally a good position to hold, it would mean e.g. for lightdm to have Depends: logind | consolekit even if systemd-activation is used and sysv-init files are provided it shouldn't have Depends: sysvinit-core | systemd-sysv, since no packages should declare explicit dependency on an init-system, it's expected to have one generally. Even for systemd-ui, i'd expect it to show an error dialog can't do much here. Stepping away to a satirical case, here is how gtk+3.10 looks like with Client Side Decorations and the new-style designed GtkHeaderBar in XFCE: https://plus.google.com/106778988568562417860/posts/TFYPgcfmj9N I don't think gnome-calculator should gain Depends:gnome-shell in this case when it clearly has functional dependency =))) -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
Dimitri John Ledkov x...@debian.org writes: This confirms that systemd is not generic across all upstreams and all distributions, and everyone is maintaining their own (in part influenced by release cadence, and well distro-specific integration) Having git repos, or even distro specific branches on Freedesktop.org would help. Since well, it's suppose to be a cross distro collaboration projects. I see little point in each distribution redoing it's own stable maintainance. I'm amused by this comment given that one of the points of criticism of systemd prior to this (by people other than yourself, to be clear) was that the systemd maintainers were unwilling to apply and carry necessary modifications and patch the source as necessary. It seems like the systemd maintainers are going to get criticized by someone no matter what course of action they take. It's also worth noting that upstart in both Ubuntu and Debian carries non-upstream patches or cherry-picks, for entirely reasonable reasons. This is just something that's likely to be necessary with this sort of package. A lot of debian-specific patches would be gone, if systemd did look up daemons based on path instead of hardcoded paths, but alas that has been rejected upstream. Because it's a horrible idea that Debian has already rejected for init scripts (see /etc/init.d/skeleton), and that we certainly shouldn't introduce when switching to a new init system. Patching upstream unit files to change paths is trivial, but even better would be to convince upstream to substitute in the proper path when building the unit file. See the lbcd source package for an example of how to do this properly. As a bonus, this means that the unit files will also work if the upstream package is installed from source using ./configure, make, and make install. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
On 4 January 2014 23:13, Sjoerd Simons sjo...@debian.org wrote: On Sat, 2014-01-04 at 09:56 -0800, Russ Allbery wrote: Sjoerd Simons sjo...@debian.org writes: Not having the logind interface is a lot harder to cope with and something that will not only impact Gnome. So essentially the most likely impact of using sysvinit _without_ a provider of the logind interface would be a non-usable Gnome desktop (and potentially even GDM to be unusable) on Jessie systems. If we go with systemd, I think we have three options: 1. Allow packages that require logind to depend on systemd and require that it be used as the init system. This is certainly the simplest for packaging applications that want to depend on logind, as well as for the systemd maintainers. However, it means we lose the ability for users of at least those packages to be able to fall back on sysvinit if something goes wrong with systemd on their systems. In the past, we've tried pretty hard to provide that capability when making a disruptive change of this kind. This one feels like a bit of a cost/benefit analysis to me. Is it worth it to force all packages to work properly (for some definition of properly) on a sysvinit system even in cases where this is a non-trivial amount of work? For e.g. daemon packages where this typically is a matter of keeping/writing an init script the cost is obviously very low, so probably worth it. For something like Gnome, it's a lot less obvious in my opinion. 2. Package logind separately from systemd, get it working with sysvinit. The problems with doing this, as I understand it, is that we'd not be able to upgrade such a separately-packaged logind beyond 204 for jessie. I'm not sure how much impact that would have. Also, it sounded to me like we would need to figure out who was going to do that work and maintain that package, including in the stable release. If the current systemd maintainers are not interested in doing this, we absolutely shouldn't try to force them to do so. Someone else would need to step forward to do this and figure out the right package relationships. (Also, it would be good to maintain this separately so that the systemd maintainers could move forward with newer versions of systemd, including the logind built from its source.) 3. Get GNOME working at some level without logind. I think it would be entirely acceptable for there to be some loss of functionality when GNOME is started in this way, such as no user switching and some configuration and control panels that rely on logind functionality not working. But it would need to at least start and be basically functional for this to be a meaningful option. The problem with this option is how to define some level and basically functional.. If it's enough to be able to login, launch some applications and have some basic window manager functionality that's probably possible. However some functionality which I would find pretty basic, e.g. configuring the network, suspending the machine, locking the screen might not be available. Also, would basic functionality mean that if things fail they fail gracefully? Given modern Gnome essentially doesn't get tested in a non-systemd environment anymore I'm sure there a lots of rough edges around. None of these options are very appealing, but I think we have to pick one of them. I'm not seeing other options at the moment. I think option 3 would be the most appealing for the project as a whole, but I realize that's also the option that puts the most burden on GNOME maintainers. The only upside I can offer for that is that this would be in the context of moving forward with systemd and would be a one-release issue. Post jessie, you'd be able to move forward with a standard integration. It's worth noting that option 3 is also what would be required if we wanted to support GNOME on kFreeBSD. I'm not sure if anyone is working on that port or sufficiently interested in it to try to make it work, but there may be some additional resources there. Actually for the project as a whole and for porting to KFreeBSD i would find option 2 more appealing as a starting point. logind is not just used by GNOME, so doing so is more generally useful. Especially for KFreeBSD as it lowers the barrier for entry for all logind users. Do you think there's a way that we could make option 3 work that the GNOME maintainers would be comfortable with? Do you think there is a way you can find someone willing to do the work? :).. The problem with both 2 and 3 is that it's work that needs to be done and maintained at least until Jessie is released. Which is work that as far as I'm aware nobody in the current Gnome team is motivated to do. So unless someone volunteers to take up the challenge to do the required work (and succeeds in doing so!), to me the options of
Bug#727708: init system discussion status
Dimitri John Ledkov x...@debian.org writes: On 5 January 2014 00:07, Nikolaus Rath nikol...@rath.org wrote: I think that if a program functionally depends on another, but the package does not declare this dependency, then it's a bug. So in this context I consider functional dependencies and package dependencies to be the same. Whilst generally a good position to hold, it would mean e.g. for lightdm to have Depends: logind | consolekit even if systemd-activation is used and sysv-init files are provided it shouldn't have Depends: sysvinit-core | systemd-sysv, since no packages should declare explicit dependency on an init-system, it's expected to have one generally. Even for systemd-ui, i'd expect it to show an error dialog can't do much here. We already have a project definition of various types of dependencies that we can use, namely Policy 7.2. My guess is that everyone is okay with packages declaring Recommends on an init system in the sense of that definition. The current debate has been about a Depends relationship in the sense defined in Policy, or at least that's what I think it's about. (Note that nothing in the above paragraph should be taken to mean that I think packages should be free to declare a Recommands in such a way that would cause the system's init system to be changed during an upgrade without coordination with the rest of the project. That's something we may want to do somewhere, carefully, as part of a transition, but it's something we would want to plan as a project, not something that I think it would make sense for individual maintainers to add in isolation. But there are various reasonable ways of avoiding that or coordinating it.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
On 5 January 2014 01:26, Russ Allbery r...@debian.org wrote: Dimitri John Ledkov x...@debian.org writes: This confirms that systemd is not generic across all upstreams and all distributions, and everyone is maintaining their own (in part influenced by release cadence, and well distro-specific integration) Having git repos, or even distro specific branches on Freedesktop.org would help. Since well, it's suppose to be a cross distro collaboration projects. I see little point in each distribution redoing it's own stable maintainance. I'm amused by this comment given that one of the points of criticism of systemd prior to this (by people other than yourself, to be clear) was that the systemd maintainers were unwilling to apply and carry necessary modifications and patch the source as necessary. Oh, that's interesting. I guess I have misunderstood your opinion email where you hail systemd as grand unifying interface. I shall re-read your that email, in light of all follow ups. It seems like the systemd maintainers are going to get criticized by someone no matter what course of action they take. It's also worth noting that upstart in both Ubuntu and Debian carries non-upstream patches or cherry-picks, for entirely reasonable reasons. This is just something that's likely to be necessary with this sort of package. Sure, the scope and size of the two, is however, greatly different. A lot of debian-specific patches would be gone, if systemd did look up daemons based on path instead of hardcoded paths, but alas that has been rejected upstream. Because it's a horrible idea that Debian has already rejected for init scripts (see /etc/init.d/skeleton), and that we certainly shouldn't introduce when switching to a new init system. Patching upstream unit files to change paths is trivial, but even better would be to convince upstream to substitute in the proper path when building the unit file. See the lbcd source package for an example of how to do this properly. As a bonus, this means that the unit files will also work if the upstream package is installed from source using ./configure, make, and make install. Oh that indeed would be wonderful, why did systemd upstream advocate for hardcoded paths in so many projects then, instead of atleast runtime detected?! How is this suppose to work with 3rd party recompiled packages and e.g. installed in opt? previously just adding opt to PATH, or droppings things into /usr/local/, enabled to use custom compiled ad-hoc replacements as desired by deployments. -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
Dimitri John Ledkov x...@debian.org writes: Imho that's a gross overstatement. Over more than a year, an Ubuntu GNOME team was established and became official ubuntu flavour with so goal and purpose of shipping GNOME3 in it's full glory. If distro watch is any indication they are fast growing ubuntu flavour, outpacing the more established ones like e.g. Xubuntu. The demand for such flavour is growing, with highly positive reviews from critics and general public. There is a group of volunteers who contribute to making it work. I've personally used it, and it's quite wonderful and capable desktop environment. I think there is some degree of heresy to claim that GNOME3 is only supported with systemd-init pid1. That was the case intermittently, until majority of pid1 checks were replaced by more correct ones. Insofar as this is evidence that it's possible to make GNOME work with option 2 (run logind without systemd), this is certainly valid information, but I think this is information that we already have. As I said in my original writeup, I believe the main challenge with option 2 for jessie is not in figuring out *how* to do the work, but in identifying *who* is going to do the work. (Beyond jessie, this will require ongoing resources to maintain if it's not purely a transitional issue, but that's a somewhat separate discussion.) And I'll note that Sjoerd said exactly the same thing. Saying that it's easy is fine, particularly if you have details as to why it's easy. What we're not going to do is say that therefore the existing GNOME maintainers in Debian must do it. That is not how we work as a project, and that is not how we're going to work as a project. If they don't want to do the work, no one is going to force them to do it. Please instead note Steve's comments on maintaining logind as a separate package, which is the productive way forward and is a way to get to the second solution in my original message. Volunteering to do the work and finding a way to do it in a minimally intrusive fashion is the way to show that it's straightforward. Even if that was the case, why should one Desktop Environment dictate for all Debian users what the pid1 should be? We are debating this decision not only on behalf of Debian developers, maintainers of GNOME, but ultimately on behalf of all our users. Which significantly includes !gnome3 and/or headless deployments. I think you have gotten confused as to which part of this thread that you're participating in (which is understandable, given that it's a giant). This discussion was prompted by my question to Sjoerd about what the impact to GNOME would be for supporting sysvinit in jessie, and for supporting a configuration without logind in jessie. That's information that we need to have in the Technical Committee in order to decide what options are reasonable to include in a discussion. Sjoerd was responding to that question in his role as a current Debian GNOME maintainer based on his experience with the packaging and with the current GNOME code requirements. In other words, this discussion is specifically about GNOME because I *asked* for it to be specifically about GNOME, because we have some reason to believe it might be particularly heavily impacted. If you have a separate analysis, I also very much appreciate your comments and analysis. But getting upset at him for providing his opinion is directly counterproductive and just makes it harder for the Technical Committee to do its work. Now it's less likely that someone else with relevant technical knowledge will be willing to volunteer it in public, for fear of having someone else jump on them. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
Dimitri John Ledkov x...@debian.org writes: On 5 January 2014 01:26, Russ Allbery r...@debian.org wrote: I'm amused by this comment given that one of the points of criticism of systemd prior to this (by people other than yourself, to be clear) was that the systemd maintainers were unwilling to apply and carry necessary modifications and patch the source as necessary. Oh, that's interesting. I guess I have misunderstood your opinion email where you hail systemd as grand unifying interface. I shall re-read your that email, in light of all follow ups. If you think that I said systemd is a grand unifying interface, you should definitely re-read my email. It seems like the systemd maintainers are going to get criticized by someone no matter what course of action they take. It's also worth noting that upstart in both Ubuntu and Debian carries non-upstream patches or cherry-picks, for entirely reasonable reasons. This is just something that's likely to be necessary with this sort of package. Sure, the scope and size of the two, is however, greatly different. My position on this is that both the upstart maintenance team in Debian and the systemd maintenance team in Debian are competent, respected, capable Debian developers, and I trust them to know how to maintain their packages. The pace of systemd development compared to the pace of upstart development is certainly something to weigh as part of the overall decision. Different people can arrive at different conclusions about that, and I definitely respect the opinion that it's moving too fast and is not stable enough to adopt, although I don't share it. But when it comes to the exact details of how the maintainers are going to handle patches and bug fixes and a release process, I see no reason not to trust the maintainers of both packages to do their jobs. Patching upstream unit files to change paths is trivial, but even better would be to convince upstream to substitute in the proper path when building the unit file. See the lbcd source package for an example of how to do this properly. As a bonus, this means that the unit files will also work if the upstream package is installed from source using ./configure, make, and make install. Oh that indeed would be wonderful, why did systemd upstream advocate for hardcoded paths in so many projects then, instead of atleast runtime detected?! How is this suppose to work with 3rd party recompiled packages and e.g. installed in opt? The approach used in the lbcd package should work with cases like that. I welcome feedback on any issues I might have missed. previously just adding opt to PATH, or droppings things into /usr/local/, enabled to use custom compiled ad-hoc replacements as desired by deployments. Not with init scripts in Debian it doesn't. Go look at the existing init scripts and count how many use relative paths for their daemons and don't reset PATH at the start of the script. I'm not just making this up. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
On 4 January 2014 19:42, Tollef Fog Heen tfh...@err.no wrote: ]] Dimitri John Ledkov Also which upstream are staying with? systemd upstream git history[4] has only one branch, which is linear with linear version number increments, without any stable release branches or other indications of which patches are stable (or possibly security) bugfixes. That's generally communicated in the release announcements as well as on the systemd-devel mailing list. having a easily accessible stable branches, as e.g. by Zbigniew Jędrzejewski-Szmek, would help a wider range of developers and sysadmins to check for bugfixes of discovered bugs. Fedora 19 appears to be packaging patches from v204-stable branch which I can't find anywhere public. Thankfully it's not a single giant patch as it's done by RedHat for their kernels, but actually git am formatted series of 116 patches[5]. Were you unable to find http://pkgs.fedoraproject.org/cgit/systemd.git/log/?h=f19 ? It's where Fedora has all of their packaging.. As explained by Zbigniew Jędrzejewski-Szmek, that is not actually where that happens. that is a one to one mapping with src.rpms and builds dispatched to Koji. I am well aware of Fedora packaging practices, and although I am yet to have an update/package accepted into fedora, I frequently monitor and cherrypick patches from Fedora for packages that I maintain, or bugfixes I work on. My comments were raised on inspection of that repository (or src.rpm which are equivalent) and spec file, to notice that a static git patch series is maintained from non-identified location, which I have also failed to locate. Fedora/RPM based distributions are significantly different, thus it is inevitable that we'll have to maintain a fork of systemd for best integration into Debian. This does not seem evident from the current systemd maintainers, which file bugs to disable/remove/override debian functionality and components with inferior systemd counterparts. Can you provide bug numbers for those allegations, please? http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;bug=716812 Rejections on mailinglists and else where to split: /lib/systemd/systemd-multi-seat-x /lib/systemd/systemd-timedated /lib/systemd/systemd-localed /lib/systemd/systemd-logind /lib/systemd/systemd-hostnamed from systemd package to individual packages binary packages, or at least together but separate from systemd-init. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719738 - udev follow upstream change, granted, steps have later been taken back to preserve backwards compat. These are just some that I have been involved in. [4] it appears that upstream git is used as packaging basis, instead of the tarball which has pre-generated documentation and loads of other files. If you here are talking about the systemd packaging, it seems you've misunderstood something. What are you missing in the source package? I've downloaded systemd_204.orig.tar.gz from debian mirror - 3ba441b51a390c6afc21e9a8a4811698 And i've downloaded systemd-204.tar.xz from systemd upstream - a07619bb19f48164fbf0761d12fd39a8 The diff between the two is http://paste.debian.net/74333/ - 477 files changed, 566 insertions(+), 246 deletions(-). I don't believe i'm missing anything in the source package, but because packaging doesn't seem to use debian/patches directory, does not use upstream published tarball, and does not have recommended get-orig-source target, it's very hard to see and instepect how and why upstream tarball is repackaged and more importantly what's changed. Even further looking at the git history in the declared packaging: it mixes upstream commits with packaging, not-rebased and not-linear, with some git-buildpackage features - e.g. the pristine-tar branch and commits of the upstream 204.orig.tar.xz, which at the end is not the tarball uploaded into the archive. Does this answer what I am missing in the source package? apart from physical files, audit trail would be a good start or at least following any of the practices adviced by the debian policy - patch target, 3.0 (quilt) format, using upstream tarballs, get-orig-source target if upstream tarball is not used, or after all that README.source explaining things... -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
On 5 January 2014 01:46, Russ Allbery r...@debian.org wrote: Dimitri John Ledkov x...@debian.org writes: Imho that's a gross overstatement. Over more than a year, an Ubuntu GNOME team was established and became official ubuntu flavour with so goal and purpose of shipping GNOME3 in it's full glory. If distro watch is any indication they are fast growing ubuntu flavour, outpacing the more established ones like e.g. Xubuntu. The demand for such flavour is growing, with highly positive reviews from critics and general public. There is a group of volunteers who contribute to making it work. I've personally used it, and it's quite wonderful and capable desktop environment. I think there is some degree of heresy to claim that GNOME3 is only supported with systemd-init pid1. That was the case intermittently, until majority of pid1 checks were replaced by more correct ones. Insofar as this is evidence that it's possible to make GNOME work with option 2 (run logind without systemd), this is certainly valid information, but I think this is information that we already have. As I said in my original writeup, I believe the main challenge with option 2 for jessie is not in figuring out *how* to do the work, but in identifying *who* is going to do the work. (Beyond jessie, this will require ongoing resources to maintain if it's not purely a transitional issue, but that's a somewhat separate discussion.) And I'll note that Sjoerd said exactly the same thing. Saying that it's easy is fine, particularly if you have details as to why it's easy. What we're not going to do is say that therefore the existing GNOME maintainers in Debian must do it. That is not how we work as a project, and that is not how we're going to work as a project. If they don't want to do the work, no one is going to force them to do it. Please instead note Steve's comments on maintaining logind as a separate package, which is the productive way forward and is a way to get to the second solution in my original message. Volunteering to do the work and finding a way to do it in a minimally intrusive fashion is the way to show that it's straightforward. I see thanks. I guess the only relevant addition, is that there is a pool of self-selected developers that are working on the similar type of integration issues: GNOME3 with logind without systemd-init. The Ubuntu GNOME team (packaging team is 18 people at the moment, there are more in users/qa/documentation teams ~250+ people) https://launchpad.net/~ubuntu-gnome-packaging Even if that was the case, why should one Desktop Environment dictate for all Debian users what the pid1 should be? We are debating this decision not only on behalf of Debian developers, maintainers of GNOME, but ultimately on behalf of all our users. Which significantly includes !gnome3 and/or headless deployments. I think you have gotten confused as to which part of this thread that you're participating in (which is understandable, given that it's a giant). This discussion was prompted by my question to Sjoerd about what the impact to GNOME would be for supporting sysvinit in jessie, and for supporting a configuration without logind in jessie. That's information that we need to have in the Technical Committee in order to decide what options are reasonable to include in a discussion. Sjoerd was responding to that question in his role as a current Debian GNOME maintainer based on his experience with the packaging and with the current GNOME code requirements. In other words, this discussion is specifically about GNOME because I *asked* for it to be specifically about GNOME, because we have some reason to believe it might be particularly heavily impacted. If you have a separate analysis, I also very much appreciate your comments and analysis. But getting upset at him for providing his opinion is directly counterproductive and just makes it harder for the Technical Committee to do its work. Now it's less likely that someone else with relevant technical knowledge will be willing to volunteer it in public, for fear of having someone else jump on them. I think I am confused about the giant threads, their chapters, sub-threads, sections, and individual emails. Sorry about that. -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
On Jan 5, 2014 2:39 AM, Russ Allbery r...@debian.org wrote: I'm doubtful that either of us are going to convince the other on this point. I don't consider it comparable to the other examples you're citing, and I think it's inobvious that raise(SIGSTOP) is a good technical choice. Simple, yes, but that's not the same thing. How hard would it be to write an external wrapper that converts the systemd style socket activation to the SIGSTOP protocol (for upstart invoking a systemd compatible daemon)? Or to add support to start-stop-daemon for both protocols so a reliable sysv style script is trivial for more modern daemons? Cheers, aj
Bug#727708: init system discussion status
Dimitri John Ledkov x...@debian.org writes: I see thanks. I guess the only relevant addition, is that there is a pool of self-selected developers that are working on the similar type of integration issues: GNOME3 with logind without systemd-init. The Ubuntu GNOME team (packaging team is 18 people at the moment, there are more in users/qa/documentation teams ~250+ people) https://launchpad.net/~ubuntu-gnome-packaging I suspect the Debian GNOME team would love to have that many active developers doing anything. :) I think I am confused about the giant threads, their chapters, sub-threads, sections, and individual emails. Sorry about that. That was very gracious. Thank you. And it's partly my fault. I really should have changed the Subject header. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
Anthony Towns a...@erisian.com.au writes: On Jan 5, 2014 2:39 AM, Russ Allbery r...@debian.org wrote: I'm doubtful that either of us are going to convince the other on this point. I don't consider it comparable to the other examples you're citing, and I think it's inobvious that raise(SIGSTOP) is a good technical choice. Simple, yes, but that's not the same thing. How hard would it be to write an external wrapper that converts the systemd style socket activation to the SIGSTOP protocol (for upstart invoking a systemd compatible daemon)? The wrapper would need to stay running for the life of the daemon, since it would be the PID that the init system would track. That has some drawbacks. For example, it would need to carefully pass signals along to its child process. I've written code like that before, and it mostly works for me, but I've not hammered on it very hard. Although, hm... actually, maybe it wouldn't need to stay running for the life of the daemon if it's sufficiently devious. The wrapper could fork and then exec the daemon in the *parent*, and have the *child* listen for the notification message and then kill(SIGSTOP) its parent and immediately exit. I wonder if that would actually work Apart from that, it would need some UNIX socket (or abstract namespace socket) code, but I don't think it's anything particularly complicated. Or to add support to start-stop-daemon for both protocols so a reliable sysv style script is trivial for more modern daemons? The hard part for more general support would be socket activation, particularly where you would put the configuration for how to create and bind the sockets. See: http://www.freedesktop.org/software/systemd/man/systemd.socket.html for an idea of what configuration parameters you'd need to support and that would need to be adjustable by the local systems administrator. Some of those are not broadly useful or are addressing some specific edge cases, but at least with networking sockets it's useful to have control over a surprisingly large number of different parameters. For just the notification part, it would probably be something one would build on top of start-stop-daemon's -b support. It should be possible to address the documented weakness of -b, and it should be doable, but it's a bit more complicated. Essentially, start-stop-daemon would need to implement not only the server side of the notification protocols (the waitpid and kill(SIGCONT), plus the UNIX socket stuff), but also separately be able to do much of the stuff described in the first section of: http://www.freedesktop.org/software/systemd/man/daemon.html I do disagree mildly with that documentation in a few places -- I'm dubious about changing umask, in particular -- but it's a pretty good summary of proper behavior for a fork and exit daemon. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
Le Sun, Jan 05, 2014 at 02:11:41AM +, Dimitri John Ledkov a écrit : at least following any of the practices adviced by the debian policy - patch target, 3.0 (quilt) format Dear Dimitri, the Debian Policy does not recommend one source format over another. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
On Jan 5, 2014 10:40 AM, Russ Allbery r...@debian.org wrote: Anthony Towns a...@erisian.com.au writes: How hard would it be to write an external wrapper that converts the systemd style socket activation to the SIGSTOP protocol (for upstart invoking a systemd compatible daemon)? On second thoughts, I think I meant this the other way around - systemd invoking an upstart compatible daemon, since it seems like upstart is more likely to support the systemd socket activation protocol than systemd is to support upstart's SIGSTOP protocol. The wrapper could fork and then exec the daemon in the *parent*, and have the *child* listen for the notification message and then kill(SIGSTOP) its parent and immediately exit. I wonder if that would actually work Nice :) Cheers, aj
Bug#727708: init system discussion status
Anthony Towns a...@erisian.com.au writes: On Jan 5, 2014 10:40 AM, Russ Allbery r...@debian.org wrote: Anthony Towns a...@erisian.com.au writes: How hard would it be to write an external wrapper that converts the systemd style socket activation to the SIGSTOP protocol (for upstart invoking a systemd compatible daemon)? On second thoughts, I think I meant this the other way around - systemd invoking an upstart compatible daemon, since it seems like upstart is more likely to support the systemd socket activation protocol than systemd is to support upstart's SIGSTOP protocol. This, sadly, is slightly harder, since you can't use this hack: The wrapper could fork and then exec the daemon in the *parent*, and have the *child* listen for the notification message and then kill(SIGSTOP) its parent and immediately exit. I wonder if that would actually work because the child can't waitpid its parent and get notified when the parent stops. So the compatibility wrapper would have to stick around for the lifetime of the daemon and pass signals and the like, and I'm not sure what gotchas would be involved in that. But it's probably doable. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
Russ Allbery r...@debian.org writes: This, sadly, is slightly harder, since you can't use this hack: The wrapper could fork and then exec the daemon in the *parent*, and have the *child* listen for the notification message and then kill(SIGSTOP) its parent and immediately exit. I wonder if that would actually work because the child can't waitpid its parent and get notified when the parent stops. So the compatibility wrapper would have to stick around for the lifetime of the daemon and pass signals and the like, and I'm not sure what gotchas would be involved in that. But it's probably doable. (Why can't I have brainstorms *while* I'm writing mail instead of subjecting everyone to more mail?) Oh, hm, actually... the systemd notification protocol allows you to tell systemd what the actual PID of the process to manage is, using the MAINPID variable. So I think you actually could write a wrapper that starts the actual daemon as a child, waits for it to stop using waitpid, sends it SIGCONT, tells systemd that it's ready along with passing MAINPID pointing to the child process, and then exits. I'd have to try that to see if it would actually work, but I bet it would, and it would be a fairly easy program to write since you can just use libsystemd-daemon and don't have to write any of the socket code. There are probably still some gotchas to sort out, such as signals received before the child process signals readiness and how to handle them, but I think that's all doable. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
On Sun, Jan 05, 2014 at 12:54:04AM +, Dimitri John Ledkov wrote: So components inside systemd-source tree do not follow what's advised to all other projects: e.g. link or statically include sd_* helper files, and perform runtime checks? The advice for other projects assumes that systemd is optional. systemd components assume that they will be installed as part of systemd, so such compile time checks would make little sense. Various configure swithes can be used to disable components, but not the main systemd part. How much functionality / api is exported by libraries/dbus of systemd to move components out of the systemd tree and into separate projects. systemd components share the same codebase, and they all make extensive use of shared functionality (src/shared part in the source tree, but not only there) which has does not have any stable external API. So it's not possible to move out any of them in any practical sense. This is a bit like with the kernel. Or, what's more interesting, projects external to systemd integrating on the same level. E.g. in upstart, all common code is factored into stable-api/abi libnih, which is then free to use by anyone (e.g. event bridges, mount helpers, etc.) and all communication to/from upstart is exported via dbus IPC (on private socket or systemd dbus). If code-sharing is only happening by being part of the systemd codebase, that also increases barrier of entry. In systemd most of the D-Bus interface, share-library interface, and various other APIs are stable, but the internal C API is not. It simply changes too fast and it is not possible to make it public. E.g. it would be benefitial for systemd to support hallyn's cgroupmanager (which can be used standalone or not). I'm not really an expert in this area, so please don't take my words as authoritiative, but... No, it wouldn't. systemd (the binary running as PID 1) uses cgroup functionality extensively. If it was to become external (in a seperate process) some sort of of synchronous protocol would have to be used, complicating things immensly, for no gain. If it was to be used as a library, that is in theory possible, but we would replace working code with something external and not even working at this point. Also cgmanager is supposed to follow a different philosophy. Also which upstream are staying with? systemd upstream git history[4] has only one branch, which is linear with linear version number increments, without any stable release branches or other indications of which patches are stable (or possibly security) bugfixes. git notes are used to mark backport-worthy commits. See http://lists.freedesktop.org/archives/systemd-devel/2013-September/013188.html. We currently mark patches as bugfixes (which includes fixes for bugs present in the latest release, but not those introduced later), or documentation and performance improvements. Thank you for this link, I was not aware of this policy. This is the first time i see git-notes used for tracking bugs needed for stable/security/documentation, and it was hard for me to find. Does also mean such stable maintenance only started in September 2013? Or some other scheme used before that? Current debian version of systemd is v204, tagged in May 2013. In this form, yes. Fedora 19 appears to be packaging patches from v204-stable branch which I can't find anywhere public. It's my private branch I generate Fedora packages from [1]. It's the same content as in Fedora git repos [2], but in a more convenient form for me. I talked with other systemd maintainers in Fedora about making it more official and public, but we haven't found the time to do it yet. If it was to be useful to other people, it can certainly be done. Thank you for pointing out where it is. Maybe add a URL in the spec file pointing to where it is? Cause I've search hard and didn't manage to find where it's maintained. (or push a mirror to github systemd projects or some other place if you require team commit access) Either that, or fedorahosted, or the upstream... We'll have to pick something, yes. I guess that also makes the RHEL patch series based on yours/fedora releases. Are there changes that are in RHEL7 and not in fedora, your fork, and upstream? AFAIK, access to RHEL source code would require a subscription. I don't know what RHEL packages include, sorry. Debian SytemD maintainers, has the ~116 fedora's stable fixes patch series been reviewed and decided to not be applied? What about stable branches from other distributions, have those been investigated? Normally maintainers from various distros (including Fedora and Debian) upstream all bugfix patches. So pulling from upstream is enough. In my opinion it is unwise to ship something into stable, ahead of upstream doing so for their support customers (RedHat Enterprise Linux). I think you're overestimating the (direct) influence of Redhat on system upstream
Bug#727708: init system discussion status
On Sun, Jan 05, 2014 at 02:11:41AM +, Dimitri John Ledkov wrote: Were you unable to find http://pkgs.fedoraproject.org/cgit/systemd.git/log/?h=f19 ? It's where Fedora has all of their packaging.. As explained by Zbigniew Jędrzejewski-Szmek, that is not actually where that happens. Hm, I was trying to explain that it *is* where it happens. The only difference is that in the Fedora package those commits are serialized as diffs, and my git tree has them as a, well, git tree. That git repo is undiclosed only because it isn't particarly important. Zbyszek -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
Uoti Urpala wrote: 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? Wrong question. As an author of one closed-source daemon that indeed does not implement double-forking, I made my unofficial Debian package depend on the daemon package. Result: the daemon utility performs that double-forking dance for me and restarts my daemon if it crashes. If the restart-on-crash functionality is not wanted, then the regular start-stop-daemon should be sufficient. So I'd say: Debian should support daemons that don't contain double-forking or socket-opening code, and should do so without patching such daemons. Patching or providing one Debian-specific utility (e.g. start-stop-daemon) should be enough. Or in other words: it is technically possible to write a Debian-specific universal readiness protocol translator that wraps a program that provides one readiness protocol and thus makes it compatible with the init system that expects another protocol. -- Alexander E. Patrakov -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
Alexander E. Patrakov patra...@gmail.com writes: Uoti Urpala wrote: 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? Wrong question. As an author of one closed-source daemon that indeed does not implement double-forking, I made my unofficial Debian package depend on the daemon package. Result: the daemon utility performs that double-forking dance for me and restarts my daemon if it crashes. If the restart-on-crash functionality is not wanted, then the regular start-stop-daemon should be sufficient. This is fine for daemons that don't fork (as you say, start-stop-daemon is probably adequate), but less appealing for daemons that are written to require socket activation. You would basically have to write the socket binding code that systemd provides. That being said, this problem seems fairly theoretical. I'm not aware of any upstream code that *requires* socket activation and that people want to package for Debian for jessie, so I'm inclined to err on the side of supporting interoperability with sysvinit for the next stable. If the problem later comes up, we can always take a look. If we select either upstart or systemd, we're going to be taking a rather dramatic step forward. I don't think there's a need to rush it too much, and there are some major advantages in allowing users to switch back to sysvinit in jessie if they need to. (More on that in a later message.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
Ian Jackson ijack...@chiark.greenend.org.uk writes: Russ Allbery writes (Bug#727708: init system discussion status): Another issue, which I did not address here but which we should probably say something about, is that the init process 1 implementation and the system used to run daemon configuration and startup jobs is separable, and in fact is separated in OpenRC. We should be clear about what we're talking about, particularly when it comes to non-Linux ports. I'm not sure what kind of things you are proposing should be in the resolution text (or, what in my proposal is wrong). Is it not sufficient to say that people should accept openrc patches as and when the openrc policy is done ? Thinking about it some more, I think the only other place where this affects the decision is if we want to say something about requesting that the non-Linux ports adopt the same init system if they both can't use the default. We presumably wouldn't want one of them using sysvinit and the other one using OpenRC, since then we're potentially supporting three different default init systems from the perspective of what init system means to packagers (what syntax the configuration files are in). One possibilty is to explicitly say that we'll make it ourselves after the jessie release. I don't want to do this in case it turns out to be uncontroversial. Good point. I think we can just drop the mention. I'm not at all fond of this approach. Neither the upstart nor the systemd notification processes are so unreasonable as to warrant the TC explicitly asking the projects to change their designs. I think that's not the right the question. The real question is this: Are the protocols offered by systemd and upstart each so plainly reasonable, that we are willing to overrule a maintainer who feels they protocol they are asked to support is too ugly or burdensome ? Are such a maintainer's objections so unreasonable ? Ah, okay, I see what you're getting at. I think they are. Furthermore, I don't think there's any likely prospect that either will adopt a socket-based synchronization protocol other than systemd's, so saying that these aren't patches maintainers are required to take pretty much says that maintainers aren't required to integrate with the synchronization protocols. We could do that. In general, I'd really prefer to defer to maintainers on what they're willing to integrate with. I was somewhat leaning in that direction earlier, in that I'm worried pre-deciding that we're going to force maintainers to do something that might never happen just raises the discomfort level to possibly no purpose. But you're correct that it's setting up a situation where some maintainers could make life difficult for projects that people care about, and result in further arguments appealed to the TC, which is uncomfortable for everyone involved. My inclination would be to give maintainers technical advice to accept integrations with either existing synchronization protocols, but leave it as technical advice rather than the binding part of the decision. |Failure to apply reasonable patches, including failure to explain |promptly and constructively why a patch is not reasonable, is |likely to lead to the maintainer being overruled. ] I think we already covered this with should in the first sentence of this section without needing to make an explicit threat. I would like to include this because it will stiffen our resolve. I must admit I'm not particularly interested in having my resolve stiffened. It also includes the important point that it is up to the maintainer to justify non-inclusion, not the other way around. I guess the question here is how many conflicts we anticipate and whether it's worth being somewhat confrontational ourselves to head it off. If there aren't conflicts in practice, we're just creating conflict without a need. I don't think it matters a tremendous amount, though. The main practical reason for ruling this out, and converting existing packages, is that not all the ports of upstart can be expected to implement the underlying strace mechanism used by upstart to implement these. Oh, good point. I forgot about that. | Cross-init-system compatibility: | | 10. Debian contributors are encouraged to explore and develop ways in |which a package can provide support for non-forking startup in |multiple different init systems without having to have separate |support for each init system in the source package; and, ideally, |without having to have separate support for each init system in the |binary package. I don't see anything objectionable about this, but I also don't really understand why it's important for us to say it. But regardless, I think this should be in brackets? It sounds like technical advice per the preamble. Yes, I just failed to bracket it. I want to put this in because I'd like to be able to drop
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
On Fri, 2014-01-03 at 16:40 -0800, Russ Allbery wrote: Ian Jackson ijack...@chiark.greenend.org.uk writes: 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. Packages could functionally depend on systemd - one example would be systemd-ui (though it seems to be mostly abandoned, and comes from the same source; it's not really part of the machinery forming the implementation though). OTOH this doesn't have to be a package-level dependency; probably programs from such packages could just fail with an error if you try to run them after booting with sysvinit, and this would probably be the best option as switching init as a side effect of installing such a package would be questionable. One case to consider is what should happen with GNOME if it requires interfaces that nobody has implemented for sysvinit. Is it OK to show a screen saying you need to boot with systemd to use GNOME and expect GNOME users to manually install systemd? Or should there be more user-friendly automation for installing it? Or would you expect to find someone to create GNOME packages without such dependencies? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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
Josh Triplett j...@joshtriplett.org writes: 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.) Yes, this sounds right to me too. It's not the package dependency that we care about, it's whether it forces a particular init system to be PID 1. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
Russ Allbery r...@debian.org writes: I've written a version of Niklaus's rule about dependencies: Just for the record, my suggestion was to include language that regulates dependencies on the init system, but I do not have any preferences whether they should be allowed or forbidden. 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. Well, we may end up in a somewhat paradoxical situation where Debian comes with packages for alternate init systems, but at the same time cannot package any utilities specifically designed for them -- unless they are included in the alternate init package itself. 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
On Fri, 2014-01-03 at 20:26 -0800, Nikolaus Rath wrote: Clint Adams cl...@debian.org writes: On Fri, Jan 03, 2014 at 10:02:01AM -0800, Nikolaus Rath wrote: 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. There are two different kinds of dependencies: dependencies expressed in package metadata, and functional dependencies (as in whether the package does anything useful with another init). Your earlier wording sounds like it was talking about the former (installable) and Ian's proposal definitely was (explicitly mentioning package fields), but the fully working you use now sounds like it's about the latter. As the systemd-ui example shows, there could be packages which in no way can be reasonably expected to work with another init. So I think a blanket ban on functional dependencies would be wrong (which you also seem to be saying). I don't see such obvious problems with banning package-level dependencies (requiring the packages to just fail at runtime instead), and such dependencies could cause problems such a unexpectedly switching init as a side effect of installing/upgrading an unrelated package or forcing uninstall of packages if you even temporarily try booting with another init. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
So we know where Colin, Steve, Russ and I stand on the main question. If we want to make a decision soon we need to start to thrash out the details so that we have something concrete to vote on. It would be helpful to know how far along the other TC members are. So: Andreas, Bdale, Don, Keith: please let us know what you're thinking, and what more information/discussion would be useful. FAOD I don't expect all the other TC members to read the whole discussion, which is very extensive. Reading the primary statements by the other TC members who have reported so far is probably helpful. Given the politicisation of the dispute, and its very high status, I think it's important to have as many of the TC voting as possible. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
Ian Jackson ijack...@chiark.greenend.org.uk writes: Andreas, Bdale, Don, Keith: please let us know what you're thinking, and what more information/discussion would be useful. Right. I've meant to post something before now, but after returning home from a family road trip over the holidays, I was hit by a nasty cold. Feeling a bit better today. I could spend a lot of time talking about what I learned from dealing with various init system and on-demand daemon launching approaches long before Linux even existed, but since I suspect that's better done over beers at places like Debconf than here, I'll simply summarize by saying that I've found sysvinit adequate but never satisfying. Clinging to it when there are superior options available would not make sense to me. There are things about OpenRC that I find really appealing, but I agree that it seems too immature to even evaluate well, and thus I don't think it is a credible alternative to be the default for Debian GNU/Linux. So I dove in and have spent quite a bit of time learning about and studying both systemd and upstart... both of which I've basically steered clear of in the past. I've done an *immense* amount of reading, talked to many people with both strong and weak opinions about both systems, and spent a modest amount of time working with the VMs that Steve so graciously provided us to learn what each system feels like in real use. I have not (yet) used either init system on any of the machines I personally admin. It's now clear to me that systemd is technically superior as an init system to upstart. I find the dependency approach easier to think about and work with, unit files seem quite easy to craft and read, I like the status reporting and logging tools, and I find myself agreeing more with Russ that with Ian about the best way to augment daemons that might benefit from it with a readiness protocol. It bothers me on some philosophical level that so much functionality that I'd like to keep conceptually separate from an init system is being pulled in to the systemd upstream. And as someone who has spent much of my professional career working with non-x86 systems and who has worked with many non-Linux kernels in different contexts, I've found the anti-portability rhetoric from Lennart, et al, particularly grating. But a long time ago, in a rec.crafts.metalworking post about teachers, a fellow named Fitch Williams wrote that in any endeavour it is a fact that you have to succeed with the people who are willing to participate. This sentiment struck me as true enough that I added it to my quotes file, and it's one I'm often reminded of when working on Debian, where we are all volunteers who choose to be here and work on things that matter to us individually. I find it particularly relevant in the context of this init system discussion... because whether I like it or not, lots of really good work is being done by people who choose to associate themselves with the systemd project, much of which I agree is important to Debian. FAOD I don't expect all the other TC members to read the whole discussion, which is very extensive. Actually, I have. I'd like to take this opportunity to thank Ian and Russ for their detailed and very thoughtful write-ups, and the various other contributors of technical input to the discussion these provoked. My opinions were formed independently, but reading through these threads really helped raise my confidence in those opinions. So, to summarize, I think systemd should be our choice for a new default init system for Debian GNU/Linux. Where I think we still need to focus attention is on how to manage the transition, and how to make *any* new init system default for Linux palatable for Debian's non-Linux ports. Bdale pgpbUTXWqENS7.pgp Description: PGP signature
Bug#727708: init system discussion status
Bdale Garbee writes (Bug#727708: init system discussion status): [stuff] Thanks for posting your views. You'll have seen Russ's comments on the details and loose ends as I call them. Russ and I were mostly agreed on these points. I have written a draft resolution from my own point of view and checked it into the tech-ctte git repo. Perhaps some of it is useful. Ansgar commented a bit on it on IRC. I guess I should post it. Ian Jackson ijack...@chiark.greenend.org.uk writes: FAOD I don't expect all the other TC members to read the whole discussion, which is very extensive. Actually, I have. [...] Thanks :-). So, to summarize, I think systemd should be our choice for a new default init system for Debian GNU/Linux. Where I think we still need to focus attention is on how to manage the transition, and how to make *any* new init system default for Linux palatable for Debian's non-Linux ports. I agree with the latter part of this. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
Ian Jackson writes (Re: Bug#727708: init system discussion status): I have written a draft resolution from my own point of view and checked it into the tech-ctte git repo. Perhaps some of it is useful. Ansgar commented a bit on it on IRC. I guess I should post it. Here's my draft. Those who prefer systemd will want to s/upstart/systemd/ and vice versa, obviously. Aside from that: 0,3,4,5,8,10 are probably not very controversial (mutatis mutandi for those who prefer systemd). 2 (non-Linux ports) needs attention in the systemd case. 6 will not be controversial (mutatis mutandi) except: 6C (and the consequential paragraphs) may be quite controversial even amongst those who prefer upstart. This needs further discussion. 7 probably needs to deal with systemd too in any case; the corresponding feature is guess main pid I think. 9's usefulness was doubted by Russ, but I hope the substance at least is uncontroversial. 11 is probably going to be thought inappropriate but I wanted to at least float it. Of course some of you may want to take a completely different approach, perhaps specifying things in much less detail. For the punt it to a GR option, I don't think we should specify this level of detail about compatibility, policy, accepting patches etc. We should provide at least four draft ballot options (upstart, systemd, sysvinit, openrc) and request that the DPL propose the GR as the TC is too unweildy for handling amendments for something time-critical like this. The ballot options we suggest should all state that sysvinit is still mandatory to support in jessie. Thanks, Ian. | Rubric: | | 0. We decide as follows (Constitution 6.1(1),(2)). Text in square |brackets [] is non-binding advice (Constitution 6.1(5)). We |require the Policy Editors (Constitution 6.1(1)) to make the policy |changes they think appropriate to give effect to this resolution. | | 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. | |[ After jessie, the policy editors may drop this requirement; |perhaps entirely, or perhaps in favour of a requirement to provide |at least one of sysvinit or systemd integration. The policy |editors may wish to refer this decision to us in due course. ] | | Policy is not ready, so hold off on updating all packages: | | 4. [ The current Debian policy for upstart, in the policy manual, |could do with some improvement and enhancement. The current Debian |policy for systemd needs to be finished and agreed, and then |incorporated in the policy manual. We encourage the maintainers of |upstart and systemd, and others, to submit relevant policy |enhancements. | |Contributors should delay introducing patches for native support |for upstart, systemd or openrc until the relevant Debian Policy is |declared, by the Policy editors, to be ready. ] | | Support requirements for packages: | | 5. Subject to paragraphs 4 and 6 of this resolution, packages should |provide native upstart jobs where relevant. | |Lack of native upstart support is not a release-critical bug for |jessie. | |[ Patches for upstart support should be treated the way release |goals have been treated in the past; so, for example, there should |be a low NMU threshold for patches meeting suitable criteria. | |The Debian Project Leader and/or applicable Delegates should give |effect to this part of our decision. ] | | 6. [ Maintainers should accept reasonable patches for native upstart, |systemd and openrc support. | |A. A reasonable patch: | (i) is proposed after the relevant policy is finalised; | (ii) complies with that policy; | (iii) complies with the advice and requirements in this | resolution; and | (iv) takes the approaches to integration chosen by upstream, | or failing that by the Debian maintainer. | |B. A patch is not unreasonable just because: | (i) the package upstream (or the Debian maintainer) does not wish | to support the relevant init system at all; or | (ii) they do not wish to support any of the suitable non-forking | startup protocols offered by that init system. | |C. However, a maintainer is entitled to consider a patch unreasonable | if it: | (i) Requires additional build-dependencies
Bug#727708: init system discussion status
On Thu, Jan 2, 2014 at 10:16 AM, Ian Jackson ijack...@chiark.greenend.org.uk wrote: Ian Jackson writes (Re: Bug#727708: init system discussion status): I have written a draft resolution from my own point of view and checked it into the tech-ctte git repo. Perhaps some of it is useful. Ansgar commented a bit on it on IRC. I guess I should post it. Here's my draft. Those who prefer systemd will want to s/upstart/systemd/ and vice versa, obviously. Aside from that: 0,3,4,5,8,10 are probably not very controversial (mutatis mutandi for those who prefer systemd). 2 (non-Linux ports) needs attention in the systemd case. 6 will not be controversial (mutatis mutandi) except: 6C (and the consequential paragraphs) may be quite controversial even amongst those who prefer upstart. This needs further discussion. 7 probably needs to deal with systemd too in any case; the corresponding feature is guess main pid I think. 9's usefulness was doubted by Russ, but I hope the substance at least is uncontroversial. 11 is probably going to be thought inappropriate but I wanted to at least float it. Of course some of you may want to take a completely different approach, perhaps specifying things in much less detail. For the punt it to a GR option, I don't think we should specify this level of detail about compatibility, policy, accepting patches etc. We should provide at least four draft ballot options (upstart, systemd, sysvinit, openrc) and request that the DPL propose the GR as the TC is too unweildy for handling amendments for something time-critical like this. The ballot options we suggest should all state that sysvinit is still mandatory to support in jessie. Thanks, Ian. | Rubric: | | 0. We decide as follows (Constitution 6.1(1),(2)). Text in square |brackets [] is non-binding advice (Constitution 6.1(5)). We |require the Policy Editors (Constitution 6.1(1)) to make the policy |changes they think appropriate to give effect to this resolution. | | 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. | |[ After jessie, the policy editors may drop this requirement; |perhaps entirely, or perhaps in favour of a requirement to provide |at least one of sysvinit or systemd integration. The policy |editors may wish to refer this decision to us in due course. ] | | Policy is not ready, so hold off on updating all packages: | | 4. [ The current Debian policy for upstart, in the policy manual, |could do with some improvement and enhancement. The current Debian |policy for systemd needs to be finished and agreed, and then |incorporated in the policy manual. We encourage the maintainers of |upstart and systemd, and others, to submit relevant policy |enhancements. | |Contributors should delay introducing patches for native support |for upstart, systemd or openrc until the relevant Debian Policy is |declared, by the Policy editors, to be ready. ] | | Support requirements for packages: | | 5. Subject to paragraphs 4 and 6 of this resolution, packages should |provide native upstart jobs where relevant. | |Lack of native upstart support is not a release-critical bug for |jessie. | |[ Patches for upstart support should be treated the way release |goals have been treated in the past; so, for example, there should |be a low NMU threshold for patches meeting suitable criteria. | |The Debian Project Leader and/or applicable Delegates should give |effect to this part of our decision. ] | | 6. [ Maintainers should accept reasonable patches for native upstart, |systemd and openrc support. | |A. A reasonable patch: | (i) is proposed after the relevant policy is finalised; | (ii) complies with that policy; | (iii) complies with the advice and requirements in this | resolution; and | (iv) takes the approaches to integration chosen by upstream, | or failing that by the Debian maintainer. | |B. A patch is not unreasonable just because: | (i) the package upstream (or the Debian maintainer) does not wish | to support the relevant init system at all; or | (ii) they do not wish to support any of the suitable non-forking | startup protocols offered
Bug#727708: init system discussion status
Cameron Norman writes (Re: Bug#727708: init system discussion status): On Thu, Jan 2, 2014 at 10:16 AM, Ian Jackson ijack...@chiark.greenend.org.uk wrote: ... | 9. [ Policy should provide non-binding suggestions to Debian |contributors who are converting daemons to upstart and/or systemd, |for example: | |(a) If changes are necessary to the core daemon code, make those |changes acceptable to the daemon's upstream if possible. | |(b) It is fine to introduce new code in the main body of the daemon |to support non-forking startup, socket activation or readiness |signalling. | |(c) Support for upstart is usually best provided with the |raise(SIGSTOP) non-forking daemon readiness protocol, unless |and until a better protocol is available. | Should it not be added that raise(SIGSTOP) should only be used with a command line option (like --debian-Z) to ensure that the daemon does not hang on sysv or systemd? I think in practice this isn't going to be much of a problem but I don't mind putting it in this section of my proposed resolution. This is advice to the the policy editors which they can ignore it if they feel it's clogging up the manual. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
Cameron Norman camerontnor...@gmail.com writes: Should it not be added that raise(SIGSTOP) should only be used with a command line option (like --debian-Z) to ensure that the daemon does not hang on sysv or systemd? No, because see Colin's point that Debian developers may be doing the integration and adding a new command-line option may conflict with upstream's intentions or just be more intrusive. Another reasonable option is to use an environment variable that you then unset after noticing its existence. There may be others. I think it's best to be agnostic in the TC decision on how this integration is done, since I think it's really a matter of technical detail and won't be controversial, and be more verbose about the options in Policy. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
Russ Allbery writes (Bug#727708: init system discussion status): Cameron Norman camerontnor...@gmail.com writes: Should it not be added that raise(SIGSTOP) should only be used with a command line option (like --debian-Z) to ensure that the daemon does not hang on sysv or systemd? No, because see Colin's point that Debian developers may be doing the integration and adding a new command-line option may conflict with upstream's intentions or just be more intrusive. Another reasonable option is to use an environment variable that you then unset after noticing its existence. There may be others. I think it's best to be agnostic in the TC decision on how this integration is done, since I think it's really a matter of technical detail and won't be controversial, and be more verbose about the options in Policy. I think it would be reasonable to state that the raise(SIGSTOP) integration should be done with a new command line option OR a new environment variable; ie that the daemon should not be changed to raise(SIGSTOP) by default. I don't know whether it's valuable to mention this explicitly. If there is any significant risk that anyone might patch a daemon to SIGSTOP by default then I would want to put something in the resolution or in policy to suggest not to do that! Would anyone really be so daft ? Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
Ian Jackson ijack...@chiark.greenend.org.uk writes: Ian Jackson writes (Re: Bug#727708: init system discussion status): I have written a draft resolution from my own point of view and checked it into the tech-ctte git repo. Perhaps some of it is useful. Ansgar commented a bit on it on IRC. I guess I should post it. Here's my draft. Thank you very much for writing this. (And, in general, thank you for often taking the initiative in producing drafts. It's something that I find difficult, and I really appreciate your work on it.) For the punt it to a GR option, I don't think we should specify this level of detail about compatibility, policy, accepting patches etc. We should provide at least four draft ballot options (upstart, systemd, sysvinit, openrc) and request that the DPL propose the GR as the TC is too unweildy for handling amendments for something time-critical like this. The ballot options we suggest should all state that sysvinit is still mandatory to support in jessie. That sounds right to me too. | Rubric: | | 0. We decide as follows (Constitution 6.1(1),(2)). Text in square |brackets [] is non-binding advice (Constitution 6.1(5)). We |require the Policy Editors (Constitution 6.1(1)) to make the policy |changes they think appropriate to give effect to this resolution. | | 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. ] 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: 1. The default init(1) in jessie for linux-any architectures will be upstart/systemd. 2. The default init(1) in jessie for non-Linux ports will be upstart/systemd if that init system has been ported and confirmed by the porters to be working by the time of the jessie release. Failing this, the default init(1) in jessie for non-Linux ports is left to the discretion of the maintainers of that port. [ However, the Technical Committee requests that, should upstart/systemd not be available for either Hurd or kFreeBSD ports, the Hurd and kFreeBSD porters agree on a single alternative init(1) implementation that will be shared by both ports. ] I'm not sure the point of the bracketed text in yours and whether I've addressed it. Another issue, which I did not address here but which we should probably say something about, is that the init process 1 implementation and the system used to run daemon configuration and startup jobs is separable, and in fact is separated in OpenRC. We should be clear about what we're talking about, particularly when it comes to non-Linux ports. | 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. |[ After jessie, the policy editors may drop this requirement; |perhaps entirely, or perhaps in favour of a requirement to provide |at least one of sysvinit or systemd integration. The policy |editors may wish to refer this decision to us in due course. ] This seems okay, although I have a minor preference to just omit this part, since I think it casts Policy in a somewhat weird role and I'm also worried about resources for the Policy process in making that sort of decision. (I'm committing to work on Policy for upstart and systemd support for this specific decision, but can't commit jessie+1 resources.) That's why I was proposing having the TC make the decision now about whether we drop compatibility with sysvinit in jessie+1. If we don't make it, someone else needs to make it, and I'm not sure who that body would be. One possibilty is to explicitly say that we'll make it ourselves after the jessie release. | Policy is not ready, so hold off on updating all packages: | | 4. [ The current Debian policy for upstart, in the policy manual, |could do with some improvement and enhancement. The current Debian |policy for systemd needs to be finished and agreed, and then |incorporated in the policy manual. We encourage the maintainers of |upstart and systemd
Bug#727708: init system discussion status
Ian Jackson ijack...@chiark.greenend.org.uk writes: I think it would be reasonable to state that the raise(SIGSTOP) integration should be done with a new command line option OR a new environment variable; ie that the daemon should not be changed to raise(SIGSTOP) by default. Agreed. I don't know whether it's valuable to mention this explicitly. If there is any significant risk that anyone might patch a daemon to SIGSTOP by default then I would want to put something in the resolution or in policy to suggest not to do that! Would anyone really be so daft ? I think this falls under Manoj's old saying that it's not the role of Policy to rule out all possible bugs. That's such an obviously wrong thing to do that I'm not sure we really need to say it, although there's no harm in saying it, I suppose. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
Russ Allbery writes (Bug#727708: init system discussion status): Thank you very much for writing this. (And, in general, thank you for often taking the initiative in producing drafts. It's something that I find difficult, and I really appreciate your work on it.) Thanks. I agree with much of what you say. I will deal with your comments again in more detail later, particularly the bits I don't disagree with, but for now: Another issue, which I did not address here but which we should probably say something about, is that the init process 1 implementation and the system used to run daemon configuration and startup jobs is separable, and in fact is separated in OpenRC. We should be clear about what we're talking about, particularly when it comes to non-Linux ports. I'm not sure what kind of things you are proposing should be in the resolution text (or, what in my proposal is wrong). Is it not sufficient to say that people should accept openrc patches as and when the openrc policy is done ? | 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. Ansgar said something similar on IRC. I didn't feel it worth mentioning but if you want it too then I'm convinced. |[ After jessie, the policy editors may drop this requirement; |perhaps entirely, or perhaps in favour of a requirement to provide |at least one of sysvinit or systemd integration. The policy |editors may wish to refer this decision to us in due course. ] This seems okay, although I have a minor preference to just omit this part, since I think it casts Policy in a somewhat weird role and I'm also worried about resources for the Policy process in making that sort of decision. (I'm committing to work on Policy for upstart and systemd support for this specific decision, but can't commit jessie+1 resources.) That's why I was proposing having the TC make the decision now about whether we drop compatibility with sysvinit in jessie+1. If we don't make it, someone else needs to make it, and I'm not sure who that body would be. I don't mind dropping this part entirely. Certainly I don't think we can make this decision now. One possibilty is to explicitly say that we'll make it ourselves after the jessie release. I don't want to do this in case it turns out to be uncontroversial. |Therefore if the upstart and systemd communities in Debian want the |widest adoption in the project, these problems should be addressed |by changes to the upstart and systemd package to widen their |support for different startup protocols. Ideally each init should |in any case provide support for the main protocols supported by |their competition. I'm not at all fond of this approach. Neither the upstart nor the systemd notification processes are so unreasonable as to warrant the TC explicitly asking the projects to change their designs. I think that's not the right the question. The real question is this: Are the protocols offered by systemd and upstart each so plainly reasonable, that we are willing to overrule a maintainer who feels they protocol they are asked to support is too ugly or burdensome ? Are such a maintainer's objections so unreasonable ? The init system is a core facility. Compatibility with a wide range of other projects with a wide range of different opinions amongst their developers is imporant. Supporting one more protocol is very easy for the init system. In practice if systemd and upstart each implement each other's main protocol, I would expect very few if any packages to remain unsupported. For me the objection that to invent a new protocol would be multiplying standards carries no weight. There is little cost to these competing standards, and we already have at least eight in the world (sd_notify, SIGSTOP, systemd socket activation, upstart socket activation, upstart expect fork, daemon(3), inetd, and what systemd calls simple). |Failure to apply reasonable patches, including failure to explain |promptly and constructively why a patch is not reasonable, is |likely to lead to the maintainer being overruled. ] I think we already covered this with should in the first sentence of this section without needing to make an explicit threat. I would like to include this because it will stiffen our resolve. It also includes
Bug#727708: init system discussion status
]] Ian Jackson I think it would be reasonable to state that the raise(SIGSTOP) integration should be done with a new command line option OR a new environment variable; ie that the daemon should not be changed to raise(SIGSTOP) by default. I don't see why you think that doing so because a configuration file tells it to, is wrong. I think it's a bad thing to overspecify how a daemon is configured, which I think you're doing here. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
Tollef Fog Heen tfh...@err.no writes: ]] Ian Jackson I think it would be reasonable to state that the raise(SIGSTOP) integration should be done with a new command line option OR a new environment variable; ie that the daemon should not be changed to raise(SIGSTOP) by default. I don't see why you think that doing so because a configuration file tells it to, is wrong. I think it's a bad thing to overspecify how a daemon is configured, which I think you're doing here. I basically agree with the latter point, but the reason why I wouldn't want to use a configuration file is that administrators are still going to want to start daemons by hand (such as when debugging things), presumably with the same configuration as when the daemon is run by the init system. The SIGSTOP behavior is rather confusing when you're not expecting it. That's why I prefer either environment variables (which are the easiest to keep clear of the administrator action, but which have the problem of leaking) or a command-line option (which the administrator has to remember to remove when starting things by hand, but which don't leak). I think it's important that anything we say here is marked as technical advice, as Ian helpfully distinguished in the draft proposal, which means that the TC is not *requiring* things and maintainers can go a different direction if the advice doesn't make sense. That makes it less of a specification and more of a collection of things we think make sense and that one should probably follow unless one has thought about the problem. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
