On 10/28/2014 at 12:20 PM, Russ Allbery wrote: > The Wanderer <wanderer@fastmail.fm> writes: > >> What I'm thinking of is cases where upstream has decided to depend >> on functionality that is provided by one init system but not by >> others, without graceful runtime fallback - compile-time choices, >> essentially, where functionality is omitted if the init system is >> not present. I have had the impression that GNOME is one such >> upstream, to whatever extent it has not dropped support for >> non-systemd environments entirely. > > But that's not the same sort of thing at all. > > You were talking about how to package software that supports > multiple kernels or multiple architectures but with different > capabilities on those different kernels or architectures. We have > packaging tools to deal with that, yes. We have similar packaging > tools to deal with software that supports multiple init systems with > different capabilities. It's a mostly solved problem. Is it? I thought part of the problem is that there are packages whose upstream supports (or at least enables) compiling with / without integration to functionality provided by systemd, and which are provided in Debian only as compiled with that functionality enabled, with no alternative package which omits that functionality. I had the impression that GNOME was one such (set of) package(s). It seems unlikely to me that such exclusivity would occur if packaging for both in parallel (and handling dependencies on the parallel packages) were a "solved problem" in that way. Certainly I know of no functionality to make it easy or automated to provide such packages, comparable to e.g. the multiarch package labeling... > You're now talking about packages that *do not* support multiple > init systems at all, but instead rely on capabilities that are > specific to one init system. Actually, I'm talking both about software which has been (as you put it) "ported" to support multiple init systems and, separately, about software which has not. My idea was approximately that the former could be addressed by an analog of the multi-arch "parallel packages" model, with multiple binary packages from the same source package, and the latter could be addressed by "simply" having the package manager not 'see' a particular package as being available for installation unless the environment is such that the features are expected to be provided - a stronger version of a hard dependency. The latter of those two hypothetical approaches was based on what now appears to have been a mistaken impression about the way kernel-category dependencies are handled currently. How does software which requires the features of a particular kernel currently depend on having that particular kernel active? I would have expected it to be via a dependency on 'linux-image' or 'kfreebsd-image' or the like, but at a glance I don't see my current linux-image-* package providing any such virtual package, and offhand I don't know of any kernel-dependent packages except for systemd - which does not obviously appear to express any kernel-related dependency. If such software effectively does not so depend, instead choosing to simply fail at runtime, that would be a somewhat odd design choice but might be one we could emulate for init systems... I'm not sure I'd support that approach even if so, though. >> And that's entirely my point: something which depends on a feature >> provided by a kernel or an architecture, such that it won't build / >> run properly on anything that doesn't provide that feature, can be >> packaged either so as to be compiled with support for the feature >> in environments which provide it and without support for it in >> environments which don't or so as to be available (package visible >> to the package manager) in environments where the feature is >> available and not in ones where it is not - but something which >> depends on a feature provided by an init system cannot AFAIK be >> packaged in a comparably varying way, with the current packaging >> infrastructure. > > This is a bad comparison. You're comparing software that has been > ported to multiple architectures (with some degredation of > capabilities) to software that has not been ported to multiple init > systems at all. You can't do that and arrive at any meaningful > conclusions; you're comparing apples to oranges. I thought I'd adequately allowed for both sides of that? The "software that has been ported" would fall under "can be packaged so as to be compiled with / without support", and the "software that has not been ported" would fall under "can be packaged so as for the package to be available when the functionality is and not when the functionality is not". Is that not enough? There would certainly be obstacles, possibly prohibitive ones, to implementing the latter - beyond just the "package depends on package-which-sets-X-as-init-system" approach which is what has been being used so far, and which has its already-seen downsides. > The comparison for init systems that would actually be equivalent is > software that supports socket activation but falls back on binding > its own sockets; that's equivalent to software that works on > multiple architectures with some degredation of capabilities. Those > packages are uncontroversial in this whole debate. I would argue that this latter type of software should be encouraged, but that's a bit of a separate (branch of) discussion - though one which I'm fairly sure is related to this GR, in terms of the underlying motivation. > The controversy is all about software that isn't portable, software > that does the init system equivalent of requiring the Linux kernel. > Such software wouldn't work on FreeBSD without substantial work > rebuilding the same features or writing glue libraries for FreeBSD. > The approach we've taken with such software in the archive in the > past is to just mark it as Linux-only until someone has a chance to > port it. That's controversial for init systems, so far as I can > tell, mostly because the platform to which the software has not been > ported is more widely used, and the software used to be portable to > other init systems but the portability was dropped upstream as > unmaintainable. But, technically, it's basically the same problem. This seems correct to me. >> In the past, we have had two major things of which you can only >> have one, of which every system must have one, and which provide >> differing feature sets in a way which can matter at runtime: the >> running kernel, and the CPU architecture. > > No, there are lots of things like that. Other major things of which > you have only one include libc, udev, a mail transport agent, the > compiler, and /bin/sh, just off the top of my head. I'm sure there > are many more. udev and possibly the MTA is a point, but if you can only have one libc installed at a time, that's news to me. Certainly any given program can link with only one, and some programs may not work with some libc implementations, but I wouldn't have intuitively expected having a second libc installed separately (and linked against by whatever you want to compile against it) would be a problem... As to the compiler, I either have to disagree with you, or misunderstand what you're talking about. It's certainly possible to have multiple compilers installed and functional side-by-side on a single machine, you just can't have more than one of them set as 'cc' or the equivalent - which is just a matter of the per-invocation default, really, rather than a system-wide exclusive configuration. That even seems to be mostly supported, at least as far as multiple versions of gcc. /bin/sh is, again, per-invocation at least to a degree. You could theoretically dynamically swap the /bin/sh symlink in between script invocations, and have everything continue to work. This is more rigid than the compiler, but considerably less so than the kernel or the init system. > With all of those facilities, we've taken different approaches; with > the mail transport agent, for example, we've defined an interface > that all mail transport agents are required to implement, and MTA > implementations that don't implement that interface aren't allowed to > provide a mail transport agent. We did something similar with > /bin/sh. Something like this might not be a bad idea for the init system, as well. Though settling on something that wouldn't be at least as controversial as the current flap might well be prohibitively difficult. > udev is an interesting example here, and I think is quite similar to > the situation at present with logind. Not just logind, but I agree, there are definitely parallels. > It was quite controversial when it first showed up, but it was so > vastly, obviously superior to the solutions that we had available > before then that it was widely adopted upstream and by packagers in > the archive. Some people were quite upset and frustrated that they > couldn't easily run systems without udev, but no real competitor to > udev ever materialized. This seems to make the same assumption that seems to have been made in some of the pro-systemd arguments: that the problem is with the implementation, not with the idea of doing it at all. "If you don't like X, do the work to implement an alternative / competitor" does not seem to take into account that "this isn't needed or desirable at all!" perspective, for which there does not seem to be any work which could be done. (Short of forking every upstream which chooses to depend on the X in question, which is a vastly larger project than "just" implementing an alternative.) Maybe it's reasonable to reject that perspective, if indeed the tool at hand is so greatly superior to the "nothing (new) at all" status quo - but it still seems like unfair argument to phrase the discussion in a way which fails even to recognize it as existing. > So we adopted udev and moved forward, and now it's hardly > controversial at all. It's my understanding that there are still people who still dislike it, for the same reasons as initially - they just don't speak up, because the battle is long since lost. I've encountered (and, to a lesser extent, experienced) enough irritation with dynamic device changes which I think are udev-related to find that plausible, at least. > That appears to be what's happening with logind right now; the effort > is being focused on making it work without systemd as the init > system, rather than on writing something equivalent to use instead. I think that's at least in part because the alternative (push back on upstreams to not require logind, or to do so only optionally, with runtime fallback) is seen as completely futile, especially without the support of a distro as backing. I think that's probably a large part of the motivation of those who want Debian to formally support multiple init systems (in the sense underlying this GR): to be able to have Debian's weight behind efforts to persuade upstream to support such cross-init-system interoperability. >> I had to blink at this for a moment. Can you please confirm that >> you're saying that having e.g. a GNOME package (or package >> collection, interlinked by dependencies, since GNOME is obviously >> far more than one package) which is built with a dependency on >> logind for environments where the functionality of logind is >> available, and built without that functionality for environments >> where that functionality is not available, would be trivial? > > If GNOME supported being built without those features, yes, it's > fairly straightforward. I probably overstated it by saying it's > trivial, but I don't think it would be that hard. But that's from > the *packaging* perspective, which is the part of the ecosystem that > you were addressing. > > GNOME upstream has not chosen to make those features optional, for > reasons of maintainability at their end, so it's not trivial, but not > for any packaging reasons. Hmm? I had been given to understand (based I think on debian-devel discussion) that these features *are* compile-time optional for GNOME, inasmuch as GNOME can still be built / used on non-Linux platforms for which logind and its functionality are not provided at all. Or has GNOME actually officially dropped support for non-Linux, and I just haven't heard about it? > Thankfully, we haven't had to do much of this because systemd > provides facilities for runtime detection and packages that are > portable to multiple init systems generally just use those. I was not aware that such runtime detection was available, much less that it was widely used. That does change the picture rather drastically. >> Except that it seems very plausible that systemd will keep adding >> such features, and systemd-shim will have to keep chasing systemd, >> and there will always be a lag in the implementation of the new >> features. > > Welcome to porting. This is true of every software port. This is > work, yes, but this isn't any sort of unusual work that we've not had > to do before. The OpenSSH packages in the archive are in exactly > this situation; the upstream is the OpenBSD OpenSSH, and the portable > version keeps chasing it. But this is something that's systematized > and reliable and no one gives it a second thought any more. I was presenting this more as an argument that systemd-shim as a separate project is not a good approach. (OpenSSH is a matter of a fork, not of a compatibility layer or the like which is what systemd-shim more or less is; that seems qualitatively different to me.) The better option would be to either incorporate "standalone" functionality like that of systemd-shim in the systemd project itself, or convince upstreams to limit their dependencies such that no such shim layer is necessary. <snip quite a bit that I mostly agree with> >> Plus I think I saw a bug discussion whose result was that >> systemd-shim will depend on having systemd-the-package installed, >> so as to be able to call features which it provides, rather than >> implementing them independently... which would avoid some problems >> which have occurred as new features or other changes get >> implemented in systemd, but which would mean that you couldn't use >> systemd-shim "without running systemd itself". > > This has always been the case since the creation of systemd-shim. > That's why it's called systemd-shim. But it doesn't require running > systemd as process 1. Er... no, it hasn't been the case, at least not that I'm aware. systemd-shim 8.2 and 7.1 do not list a dependency on systemd, or appear to invoke one indirectly; as far as I recall, no such dependency had previously been present, either. Attempting to install systemd-shim and remove systemd in a --dry-run does not complain. The discussion on bug 765101 contains a suggestion to add such an explicit dependency, and this suggestion appears to have been accepted by the maintainer for systemd-shim 8.4. (This seems to be due to a difference in dbus policy files between the two, not as I thought to a need to actually run systemd for systemd-shim, but the basic point still holds.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature