Bug#727708: init system coupling etc.
On Wed, 2014-02-12 at 23:30 +0200, Adrian Bunk wrote:
> On Wed, Feb 12, 2014 at 06:09:38PM +0100, Lucas Nussbaum wrote:
> > Hi,
> > I must admit that I only followed this part of the discussion from a
> > distance.
> > However, one thing really strikes me:
> > On 12/02/14 at 14:08 +0000, Ian Jackson wrote:
> > > [loose coupling]
> > >
> > > Software outside of an init system's implementation may not require
> > > a specific init system to be pid 1, although degraded operation is
> > > tolerable.
> > This is super vague. What does being "outside of an init system's
> > implementation" mean? What does "degraded operation" mean?
> > If you really want to have that discussion now, rather than wait for
> > actual, concrete problems to discuss, I'd suggest that you build a few
> > hypothetical scenarios, and discuss them. And then build a resolution
> > that represents the aggregated opinions on those few hypothetical
> > scenarios.
> > But I also don't really understand why there's a particular urgency
> > for the TC to rule on that. Are there packages with tight coupling
> > already in the archive?
> One of the Debian GNOME maintainers has stated in this discussion:
> But there are no realistic solutions for having GNOME support multiple
> init systems in jessie.
> Whether that's actually true is another question, but a maintainer
> speaking like this clearly shows that it is not only a theoretical
Please don't quote people out of context. The problem with quoting lines
like that is that "support" means different things to different people.
The definition of "support" has two extremes:
* Fully functional, all features work as they should etc.
* Degraded but functional, It's usable but some functionality might
not work, errors may show up in some places etc.
Re-reading Joss' mail i can only assume with support he means the former
option. However lets not make this about rehashing the mail of one of my
fellow GNOME maintainers.
So for some less hypothetical, more practical considerations:
As long as there is a logind implementations available in Debian which
works with non-systemd, Gnome can depend on that as an alternative to
the systemd provided version and it should be possible to at least
support degraded mode for other init system for the foreseeable future.
As things stand, there seems to be more then enough motivation to ensure
an implementation of the logind interfaces is available for use on
non-systemd even when the systemd package get moved to a newer version
and it's own implementation does not support that anymore. In which case
we can add an alternate dependency on an alternate logind implementation
Ofcourse the more complete the alternative implementations are of the
systemd services are, the better the Gnome experience can be for those
choosing gnome but not systemd. For example systemd-shim seems to be an
effort in this direction.
None of this is rocket science and none of this requires a pre-emptive
resolution on the TC side to decide what dependencies are generally
allowed (which probably would do more harm then good). Advise, is
ofcourse always welcome, but lets try and solve technical problems with
technical solutions rather then politics as in the end that's what we
tend to do best.
> Another reason for urgency is that there was actually consensus
> in the TC that Debian should multiple init systems. That was
> completely lost in all the "Debian chooses systemd" headlines that
> followed a widely published resolution that was only about the default
> and didn't cover that aspect.
> Or perhaps that's no longer urgent, since the "Debian chooses systemd"
> headlines are already in everyone's head, and a later statement
> "but we also support other init systems" would anyway not make it
> into the news.
I think for all of us that actually had a stake in this discussion, it
has been more then painful enough so I doubt we'll forget that aspect.
If you're aiming for headlines, i doubt re-affirming support for
multiple systems will make much of a dent there.
Sjoerd Simons <email@example.com>