Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Russ Allbery <rra@debian.org>]

The Wanderer <wanderer@fastmail.fm> writes:

> 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).

See Josselin's reply on this.  You in theory can build GNOME with
ConsoleKit support, but in terms of getting a generally working experience
for the user, it's probably less work to get systemd-shim working with
logind than to bring the ConsoleKit code up to snuff and support it.
(Although apparently someone is trying the latter, so maybe this will
change.)  Either way, this isn't a simple matter of the package
maintainers switching some flags, so adding more packaging tools doesn't
really help.

In other words, I think you're trying to solve the wrong problem.  The
problem you're trying to solve is not the obstacle that's getting in the
way of good support for multiple init systems.

> 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.

There are a ton, but because Debian architectures encode choice of kernel,
they're represented in the archive as packages that are not available for
kFreeBSD or Hurd, or only available for kFreeBSD, or only available for
Hurd.  A better example to look at if you want to see the problem handled
via dependencies would be how Kerberos packages in the archive are
handled, where basically everything is built with MIT except for a small
number of packages linked with Heimdal.  Or at the situation with OpenSSL
and GnuTLS.

> 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?

Yeah, I had missed the second part, sorry.

I think this is part of the question about how to handle installing a leaf
package that only works with systemd.  Ideally, if people have the time
and energy to keep maintaining things like systemd-shim, we avoid this
problem.  It's rather surprising to have the init system changed by
installing a package, but it's also surprising to have the package not
appear available in apt until you reboot into a different init system
(which I think is what you're proposing).  That doesn't really make sense
to me.  What we may end up with is having packages be installable but not
actually work, which is another less-than-ideal approach, but which I'm
pretty sure we currently do with various other things in the archive with
similar requirements that are hard to represent with dependencies.

> 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...

You can install a second libc, but nothing uses it, and you can't load any
shared libraries in programs built against it without rebuilding all of
those shared libraries.  So, effectively, you can install it but you can't
use it for anything other than completely isolated development, at which
point you may as well just use a chroot.  I think it's fair to say that
you can only have one libc.

> 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.

I was talking more broadly about places where Debian picks just one of
something.  I see you were talking specifically about what can be
installed on a single system; in that case, yes, you can easily install
multiple compilers.  You can also easily install multiple init systems,
but the system can only be booted with one of them at a time, which means
init systems coexist *better* than libc, but worse than compilers, and a
little worse than MTAs since you can switch MTAs without rebooting.

>> 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.

Exactly.

>> 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.

In the case of logind, the people I've seen arguing that it shouldn't have
been done at all pretty clearly didn't understand the problem space.  Note
that everyone is adopting logind, both upstream and among distributions.
Ubuntu even was when planning on staying with upstart (which is where
systemd-shim came from in the first place).  I'm sure it's possible to do
better than logind, but logind was a clear improvement over what DEs were
using to solve those problems prior to logind.

logind is the source of the (erroneous, although understandable) idea that
the systemd ecosystem is more attractive for desktops than for servers.
It turns out that systemd just as compelling for servers as for desktops
when you take a good look at it, but logind is such an obvious win for
desktops that it created that idea.

> "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.

This is for obvious reasons, no?

If something isn't required at all, people don't start using it, and
people certainly don't get so excited about it that they push hard to
adopt it broadly and start getting unenthused about working on systems
that don't have it.  So "this isn't needed or desirable at all" is an
argument that can be easily dismissed simply by looking around and seeing
the number of people who are excited about the new features and eager to
adopt them.  Specific individuals may well have no use for those features,
but the general statement that *no one* wants those features is clearly
and obviously false.

Take a step back from this particular debate and look at the broader
history of the IT field.  How many times have we seen a company or an
"industry leader" respond to the invention of something new and popular
(usually by a competitor), or some limitation in existing software or
hardware people are complaining about, with a statement like "no one will
ever need that or care about that?"  What's their track record in being
correct?

One thing that never works is claiming the excited and eager users of some
new software or product don't actually exist or, even more insultingly,
are all deluded.  Unsurprisingly, people don't respond well to being
lectured paternalistically on how they don't actually want something they
clearly want.  At best, they simply ignore you and move on.

[udev]
> 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.

There are always people who dislike any piece of software because all
software sucks.  I think the more relevant question is whether the
software sucks enough that anyone will bother to go to the effort of
replacing it.  If the answer is no, I would argue that the software is not
actually *controversial*, although it might be irritating or frustrating
or even buggy.

Some problems are hard or annoying to work on, and in those cases it's not
unusual to settle on something that few people are particularly *excited*
about, but which works well enough that it's not worth the effort to go
replace it.

> 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.

That's not a reason; that's just moving the question to a different set of
people.  Why are the upstreams dubious about investing the effort into
supporting non-logind configurations?  Either you have to go down the
mental path where you start inventing a massive conspiracy that somehow
involves alliances between projects that are openly competing, or you have
to come to terms with the fact that maybe logind is really compelling for
people who work in this space and understand the problems that it's
solving.

> 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 know that it is, but I find that baffling, since from where I sit such a
thing is clearly absurd and useless.  Since when are free software
projects convinced by louder and more demanding voices rather than
technical arguments?  The way to get upstreams to support
cross-init-system interoperability is for someone to join the upstream
project, write that functionality in a supportable way, and maintain it.

Olav Vitters from the GNOME project has been interacting on Debian mailing
lists for a while now, practically *begging* for people to engage with him
and with the GNOME developers and explain exactly what requirements they
see and how they want to address them.  I suspect the lack of meaningful
response has gotten rather frustrating.  If people want to talk to GNOME
developers, they've been openly inviting such conversation for years now.
You don't need a GR, you don't need leverage, you just need to go talk to
them and do enough research in the relevant technical space to have
intelligent and reasonable things to say.

On this front, I recommend reading what Olav wrote on this topic if you
haven't already.  I think it makes fairly clear what is going through the
head of upstreams here:

http://blogs.gnome.org/ovitters/2014/09/07/systemd-in-gnome-3-14-and-beyond/

I would particularly like to emphasize this statement, which I think is an
accurate summation of most of the arguments I see:

    If a project sees functionality within systemd that is useful, it is.
    [Y]ou'll not get very far with stating that the project is bad for
    having used that. Or suggesting that there is some conspiracy going
    on, or that the project maintainer is an idiot. That's unfortunately
    often the type of "anti-systemd advocacy" which I see.

and:

    Projects have depended on systemd because it does things which are
    useful. As a person you might not need it. The other one believes he
    does need the functionality. Saying "I don't" is not communication. At
    least ask why the other believes the functionality is useful!

> 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.

That's because the point of systemd-shim is to provide the services that
logind requires without running systemd as PID 1, so that packages can
then depend on logind without requiring systemd be PID 1.  That didn't
require a direct dependency on systemd because that dependency comes in
via libpam-systemd or some other route in the software using logind.

In other words, the whole point of systemd-shim is to enable the use of
logind.  It's not replacing it with something else.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>