The Wanderer <wande...@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. 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. That's a completely different problem, and not a problem that can be solved by some sort of packaging infrastructure. That's a straight porting problem, such as a software package that only builds on amd64. Nothing about our packaging environment is going to help with that: it's simply (possibly quite hard) work. And that's similarly true of packages that *rely* on one particular kernel, such as all the Linux-specific software we have in the archive that doesn't work on FreeBSD. Supporting multiple init systems in packaging given upstream support for building for different init systems is easy. *Porting* is hard, and there are no packaging shortcuts for that. Which is why we're having a debate over whether to allow unported software in the archive. As AJ pointed out, we've been allowing unported software in the archive for years and years. We have lots of software that only builds on a subset of architectures, or is specific to Linux, or is specific to FreeBSD. It's not at all clear to me why init systems should be any different. > 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. 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. 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. > 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. 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. With udev, on the other hand, we basically required everyone run udev; it's theoretically possible to boot a system without udev, but it's not tested and I think everyone would agree that it's not supported. For the compiler, all of Debian is built with GCC, but some teams do test builds with Clang and report bugs, which most maintainers merge and some don't. And with libc, we do not even allow for the possibility of replacing the system libc; you use glibc if you're using Debian on Linux, and that's the end of that. > (There may be an argument that there are other such things already in > place, without such special cases - libc, for example. However, AFAIK > the runtime feature sets which those provide are far closer to being > equivalent - for purposes of binary packages depending on them, anyway - > than are those of the other things listed.) No, the runtime feature set variation for libc is huge, which is exactly why we require glibc and don't even attempt to support anything else. In fact, that's true of most of the things that I named. There are huge variations in the feature set available. This situation with init systems is not at all unique, nor is it even close to the third problem we've had of its kind. Quite the contrary: it's actually very routine. We have lots of issues like this in the archive. The only differences I see in this case is that most of these other decisions were made many years ago, when the project was much smaller and picking one winner was a more natural decision, and that systemd involves a lot of design choices that are more controversial, in part because people haven't chewed on them for as long as they've chewed on the design choices in other areas. (GCC also involves a lot of design choices, including some, such as nested functions, that were also quite controversial; we're just all used to those design decisions and have ways of working around them because we've been dealing with them for a long time.) udev is an interesting example here, and I think is quite similar to the situation at present with logind. 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. So we adopted udev and moved forward, and now it's hardly controversial at all. 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 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. Rather, it's not trivial because the support for acceptable degraded operation without that functionality is not available in the upstream code base so far as I know. (GNOME maintainers should correct me here if I got the situation wrong.) There is plenty of software that does support degraded functionality without systemd features, though. For example, I have several packages that use socket activation if it is available, and fall back to doing things the old way if it is not. But GNOME wants to use logind, for which there is not currently a reasonable and maintained alternative. > What I'm arguing is that with kernels and architectures, we can build > packages differently depending on what functionality we expect to be > available in the final environment - but with init systems, as far as I > can tell we cannot easily build a single package in multiple ways > depending on what init system we expect to have available. Or at the > very least, we aren't doing it. No, the situation is essentially the same between those two cases. The difference is not at all what you think it is; rather, the difference is that the software you're looking at that works with multiple kernels and architectures (with possibly degraded functionality) has been ported, and the software that doesn't work with multiple init systems has not been ported. You're comparing portable software to nonportable software, and that's why I think you're getting confused. If the software supports being built in multiple ways depending on the running init system, we have numerous ways to deal with that right now in the packaging system. Ideally it does this at runtime (which is the most common approach with systemd features), in which case we just make one package and let it figure things out at runtime. Otherwise, we can do many other things, such as building two different binary packages for people to choose from based on their needs (similar to how we have libpam-krb5 and libpam-heimdal, or libcurl3-gnutls, libcurl3, and libcurl3-nss). Or shipping multiple binaries in the package that the user can choose between using alternatives. Or using a wrapper script or program that detects whether systemd is in use and runs the right binary for that use case. 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. > About the only way I can think of to do that under the current system > would involve having multiple binary-package names, one per different > build config, with different assumptions about environment-provided > features in each - and I would expect that that would quickly become > either very complicated or very broken once another package starts > depending on the one we're looking at. That's why runtime detection is better, but we deal with multiple binary packages with such variations fairly routinely in Debian. > 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. It remains to be seen whether there's enough long-term interest in systemd-shim for it to reach the same level of maturity, or if it will die a natural free software death. Both outcomes are possible. But there's nothing particularly special about this porting problem. It's just work. The primary reason why I am opposed to this GR is that I believe the only practical effect it will have if it passes is to become a stick to beat other people with. It will not change the chances that sysvinit will be viable in the long run. It will not increase the amount of software that will be ported (indeed, I strongly suspect it will decrease it due to irritation and demoralization from being beaten with sticks). All it will do is create arguments, anger, bad will, and fights, as people use the GR to try to hurt people who are doing things they don't like, and to try to force people to do things their own way. This attempt is fundamentally doomed, since there's no way in Debian to coerce people into doing things over the long run, but it will be considerably more unpleasant than it is already in the short run. I strongly believe that this proposal is well-meaning and put forward with the best of intentions. However, I also strongly believe that a vote in favor of it is basically a vote for constant flamewars and hostility in our community, and is likely to make it *less* likely that people will port things to non-systemd init systems due to the natural backlash against people who are not doing the work telling them how to do their work. Portability will either happen or it won't, based on people's time, desire to work on portability, willingness to build portability frameworks, and interest in keeping other init systems alive. Telling people their code *has* to be portable doesn't help. Encouraging them and providing them tools and assistance to make it portable *does* help, since it reduces the friction and work required, and that's how we've been successful in the past in getting our software to build across multiple architectures. And sometimes that's not enough -- we drop architectures all the time because there just aren't enough people interested in keeping them alive. And that's always sad, and there are always people who are upset by that. But it's just part of working on free software. Sometimes projects die natural deaths due to lack of interest, and everyone has to move on, even if they don't want to, or at least turn their work on that project into a hobby that's unlikely to attract much further attention. I've had software projects that mean a lot to me die off in that fashion, and it sucks, but trying to keep them shambling along in some undead fashion by fiat is never going to work, not in a volunteer community. That's the sort of thing that corporations do by mandating that their employees work on the dying project or be fired. We don't do that. > 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. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87wq7kgo99....@hope.eyrie.org
