Re: GR: Selecting the default init system for Debian
Hi Steve!
On Sat, 2014-01-18 at 19:16:44 -0800, Steve Langasek wrote:
> On Sun, Jan 19, 2014 at 01:01:44AM +0100, Guillem Jover wrote:
> > Moreover, none of the proponents of alternative init system seem
> > to have expended much energy in seeking wide deployment of their
> > solutions within Debian (or, with the exception of upstart, even
> > updating the policy manual) before this binding ruling was sought.
>
> […] can I ask how you arrived at the conclusion
> that not much energy has been expended on upstart in Debian?
>
> I've actually spent quite a lot of time and energy on getting upstart, and
> other base system packages, into a state that users should be able to switch
> from sysvinit to upstart without regressions. That means getting the
> ifupdown integration in place, making sure lvm and network filesystems work
> at boot, ensuring transparent handling of startpar dependencies on scripts
> that are shadowed by native upstart jobs, etc.
Sorry, that wording was probably unclear. I *do* know you have done
lots of work on upstart in Debian, that's why I also included the point
about the policy update. But here I didn't mention, on purpose, work
done on specific init systems themselves, helpers and immediate
surroundings, but on "wide deployment". I didn't mean to devalue the
work you and other upstart supporters have done (or other init system
alternative supporters for that matter), I'm sorry that might have been
your impression.
> It does *not* mean doing
> very much work on pushing native upstart jobs to maintainers of leaf
> packages; that should be secondary to getting a complete and correct base
> into Debian. But we certainly are at the point today where such jobs can be
> implemented more widely in packages.
>
> If you have a different standard for "seeking wide deployment", I'm
> interested to know what it is.
Well, for example, only just very recently it got to a point where
upstart could be installed w/o scary essential removal prompts and
similar (again, work that you did).
And yes, when I mentioned "seeking wide deployment", I meant archive
wide support. Let me try to give an analogy to clarify what I mean.
Say, the GNU/kFooBar porters might have invested lots of effort into
their kernel, toolchain and kFooBar-specific utilities, which in
addition might be in excellent shape; but if the architecture only
has 10% packages built for that port, and they stop there, then it
cannot get exposure of its possible features, advantages or different
ways to do things, and people interested in particular packages might
not see the point in even giving it a try. Expecting the project at
large to do the other 90% of the porting seems unrelalistic, even if
the system has a very solid foundation, because at this point it might
not show much advantage to the current ones. Instead I think the work
that many porters have done, by sending patches to port packages to
their systems, have in many cases triggered curiosity to the point of
people possibly experimenting with those ports, or at least seeing
value in supporting these even by themselves. There's probably many
other similar examples, like having excellent cross-building support
in the toolchain but having no actual cross-buildable package in the
archive, etc.
In the upstart case, most of the work could have been reused from
Ubuntu, w/o interfering with the current init system default. I seem
to understand reluctance to push native upstart jobs into Debian was
partially out of respect towards the project. I just think that respect
was misplaced for something that was optional, and it actually backfired.
Hope that clarifies.
Thanks,
Guillem
Reply to: