Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]
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.
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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: