[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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

> 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

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

> 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

> 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

   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

Reply to: