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

(I wonder about the extent to which this remains on-topic... I didn't
hesitate about my previous post, since it was relatively brief and
addressed what I thought was an important and relevant single point, but
this is considerably longer and gets rather farther afield.)

On 10/27/2014 at 11:54 PM, Russ Allbery wrote:

> The Wanderer <wanderer@fastmail.fm> writes:
>> Just as a note, one difference here is that there is support in
>> the archive and package-distribution mechanisms for having multiple
>> versions of a package for different architectures or (I think?)
>> kernels, so that you can build a version with some optional
>> features for one architecture / kernel but a version without those
>> optional features on another - but there is no such support for
>> having multiple versions of a package for different init systems.
>> You can only have one architecture, only one kernel, and only one
>> init system active at any given time. The archive and its
>> infrastructure recognizes this for architectures and (I think)
>> kernels, and supports special handling for them to avoid or work
>> around problems which would (or easily could) otherwise be present.
>> The archive and its infrastructure do not presently recognize this
>> or provide such support for init systems; as such, no such
>> workarounds are available.
> *looks at his packages that support systemd, upstart, and sysvinit*
> I think you're confused about where the hard parts of this process
> are.
> It's often easier to support multiple init systems in a package than 
> supporting multiple architectures or multiple kernels.  It's
> certainly nothing that tremendously difficult to do.

What sort of packages are these, and what sort of support is involved?

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.

If adding support for other init systems to such packages (so that they
do not assume the presence of certain functionality in the environment,
but either can provide it themselves, or will simply fall back to not
providing certain features if that functionality is not present) is not
difficult, then that's certainly a good thing - but that is not the
impression I've gotten from the comments thus far.

My comments were pretty much not at all about init scripts or their
equivalents, which after all are only about starting or stopping
whatever "service" is in question, but only about functionality provided
to other processes by the running init system.

> The packages that are causing all the controversy at the moment
> aren't created by some sort of archive limitations, or even by a
> breakdown of this process.  The problem, rather, is that only one
> init system (or at least one init system's infrastructure; I'm
> counting logind as part of systemd here) supports some decidedly
> non-trivial features that those packages use, and no one has provided
> a supported implementation of those features for other init systems.
> In other words, they're very much akin to ZFS on FreeBSD.

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.

I am sort-of attempting to propose a different model for expressing the
dependency of these upstreams (and the resulting packages) on the
functionality provided by one particular init system, one which might be
able to more easily allow "package with dependency and with matching
functionality" to coexist with "package without dependency and without
matching functionality".

> But we already have a reasonable workaround in the form of getting
> the systemd component to work under sysvinit.

That's a matter of providing the functionality under other init systems.
I am talking about making it (relatively) easy to provide parallel
versions of the package which work when the functionality is not
available in the environment, and/or making it possible for a package to
express its absolute dependence on the functionality in a way that does
not have such unfortunate failure states. The latter may be addressed by
systemd-shim (at least within environments which systemd itself
supports, i.e. Linux), but the former is not.

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. (Well, I imagine you *could* have a system
with multiple CPUs of different architectures, but that would be fairly
difficult to engineer in the first place.) We have special cases in the
infrastructure for both of those, to allow smoothly expressing loose vs.
hard dependencies on them, and to allow varying functionality from one
to another depending on what each supports.

Now that we have a third such thing - the init system - I am suggesting
that it might be reasonable to have a special case in the infrastructure
for that, as well, for similar purposes.

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

>> It seems possible that some of the problems potentially / arguably
>> introduced by having features provided by only a subset of
>> available init systems could be avoided or resolved by having
>> multiple package versions for different init systems,
> There's no reason to do that if someone is willing to port it.  You
> can combine it all into one package trivially.

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 that is indeed trivially possible, then it would appear I've greatly
misunderstood either the power and flexibility of the Debian packaging
model or the degree to the features for which GNOME depends on logind
are dynamically (i.e., runtime as opposed to compile-time) optional.

> That's not the hard part; the hard part is replacing the
> functionality that the package relies on but which is only provided
> by one init system.

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.

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 people are putting all that hard work into systemd-shim,
> which lets one use the systemd logind component without running
> systemd itself.  Once that work is done, then packages that rely on
> logind don't need to do anything particularly special.

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. (Unless
there comes to be active cooperation between the shim people and systemd
upstream, which I've seen no indication is likely.)

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

   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: