Russ Allbery writes ("Bug#727708: loose ends for init system decision"): > Ian Jackson <ijack...@chiark.greenend.org.uk> writes: > > For me it's a different proposition to suppose that _every_ daemon > > should bring in these kind of dependencies. > > It's only going to be *every* daemon if we select systemd as the default > init system, in which case we should be doing this in many daemons for > either socket activation or for readiness notification as part of a proper > systemd integration. [...]
Well, no. I think that even if we select upstart as the default, we should enable the systemd community to provide as complete a set of integration in Debian as they care to put the work in for. That translates directly to an expectation that the maintainer of any daemon package must be willing to accept reasonable systemd integration patches. If the systemd community is very dynamic (and certainly we can't fault their dynamism so far) this may well translate to all or almost all daemons. Certainly it could be expected to include most of the core daemons where the extra dependencies are most troublesome. So I think we need to say what we regard as "reasonable" patches, in advance. As the Debian maintainer for uservd (for example), am I entitled to decline to incorporate systemd integration into my package on the grounds that the patch involves additional build- and runtime dependencies which I consider undesirable ? I don't consider it desirable to answer this question differently for different daemons. We need to set out a clear rule for maintainers to follow or we'll end up adjudicating a gazillion individual disputes. And if the answer to this question is, in general, "the maintainer must include the patch" then the logical conclusion is that it is OK for every daemon in Debian to acquire these additional build- and runtime dependencies. We would be telling non-Linux ports that they need to arrange for these dependencies to be somehow provided despite the lack of systemd on their architecture, or to have conditional compilation of the systemd support in every daemon package. If the TC's answer is "the maintainer may reject the patch", we would be telling the systemd community that they need to improve and simplify their integration. I think the latter is the right approach, for two reasons. Firstly, it is less work overall. Secondly, it is proper that the maintainers of an init system should be encouraged to provide as simple and nonintrusive an integration interface as possible. > > This is particularly the case for build-dependencies on an avowedly and > > intentionally non-portable program. Of course this can be made > > conditional, but this is IMO too fiddly. > > Adding [linux-any] to the Build-Depends line is not too fiddly, and if the > goal is to enable optional upstream support for systemd, that will be > sufficient. Besides, in general, it's up to the packager to decide what > is or is not too fiddly in how they want to package software. Adding [linux-any] to the Build-Depends is not sufficient. It is also necessary to make the actual source code conditionally use sd_notify, using #ifdefs or other similar techniques. The conditional compilation will have to be automated (perhaps with autoconf if the package has it - an then we need new --with[out]-systemd configuration options to avoid miscompilation; or perhaps in an ad hoc way if the daemon doesn't use autoconf). The fact that the systemd-specific command line option may or may not be compiled in needs to be mentioned in the documentation, along with text which allows the user to know whether it's included in the version they actually have. This turns what could be a simple change into a multi-part epic involving all of the components of the package: primary source code, upstream build system and portability layer, Debian build system, documentation, and so on. And it might come about later that someone provides a portable sd_notify so half (but just the right half) of the above would have to be undone. > Obviously, we should not add an unconditional build dependency for a > library that isn't available on some of our ports to software that can > work on those ports. But I think that's obvious. I'm happy to have us > say that explicitly if if helps. I think maintainers should not be required to introduce the additional build- and runtime dependencies, if they do not wish to. Obviously if they want to then that's fine by me. > > It is very likely that Debian contributors will be implementing native > > support for whatever readiness protocol, in the upstream parts of the > > codebase. It is IMO appropriate for those contributors to get advice on > > how to do this. Policy already gives advice on this kind of thing. > > Given the context, and the fact that this advice is going to be read by > > a lot of people as part of a big enhancement project, I think it's > > appropriate for the TC to answer this question. > > If you feel like Policy should give advice on this, you can bring it up in > the context of Policy. The TC's mandate includes deciding on policy questions. > I don't think the exact mechanism of integration is important > enough for the TC to explicitly favor a particular mechanism, and > different upstreams may have different approaches. I'm not seeing > the important gain to Debian here in trying to standardize exactly > how one tells a daemon to use socket activation or readiness > notification. I'm not saying it should be standardised. I'm trying to give guidance to Debian contributors who will be doing this work on many existing daemons. We would like them to do the best thing and giving them non-binding guidance is correct. > I also, for what it's worth, directly disagree with this advice with > respect to systemd because I think compatibility with how systemd is used > elsewhere is more important than any marginal gain from using a > configuration method that's not inherited by subprocesses by default, > particularly given that the standard systemd APIs include environment > sanitizing. But I also don't see any point in arguing about it here, > since I don't think this dispute is ripe (in the legal sense). I'm afraid to say that this is quite a frustrating approach. If it will help I can go through the motions of filing a policy bug, having everyone point out that this is entangled with the whole init system debate, and having you reject my proposal. But perhaps we could just pretend I had done that ? > If you do bring it up in the context of Policy and we can't resolve the > debate there, it can get appealed to the TC and we can decide it here > separately, but I think this is all premature, given that the whole point > becomes basically moot if we don't pick systemd anyway. No, it doesn't become moot. If we pick upstart then we still need to tell maintainers what kind of systemd patches to accept. If anything, it becomes moot if we pick systemd. It seems unlikely that there would be a majority in the TC for picking systemd, and separately a majority in the TC for overruling the systemd maintainers' refusal to implement a simpler readiness protocol. So a decision to pick systemd automatically comes with the expectation that all daemons will get the new build- and runtime dependencies, and maintainers will be expected to accept those patches. > > Are you proposing then that the TC should decide the default init > > system, but asmk people NOT to start converting packages until the > > policy questions are settled ? > > Sure. I think that's what's going to happen anyway. I don't think that's likely, unless we state it explicitly. And I want the conversion work to be able to start as soon as possible. These questions are all entangled with the init system choice. Having dealt with the primary issue the TC members will be in a good position to dispose of these ancillary issues. I think remanding contentious consequential issues back to the policy process is a very unattractive option. It will just incur delay. I'm happy with leaving uncontentious details to the policy process. Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21187.3401.842269.255...@chiark.greenend.org.uk