Bug#727708: Init system resolution open questions
On Sun, Jan 19, 2014 at 02:59:01AM -0800, Russ Allbery wrote:
> Adrian Bunk <bunk@stusta.de> writes:
> > On Sat, Jan 18, 2014 at 08:49:48PM -0800, Russ Allbery wrote:
>...
> > No, I am not assuming bad faith.
>
> > But there will be cases where the goals like
> > 1. give users of systemd under Linux the best possible experience
> > 2. support non-Linux ports
> > 3. support other init systems
> > conflict.
>
> > What is better depends on which goal has a higher priority for you.
>
> > There shoud be a general project direction that clearly defines which of
> > these two goals has a higher priority for Debian, not half of the
> > packages going into one direction and the other half into the other
> > direction.
>
> I don't even agree with this. I think it's perfectly reasonable for some
> Debian contributors to choose to put more of their time into giving users
> of the default init system on Linux the best possible experience, and
> other Debian contributors to concentrate on supporting non-Linux ports or
> other init systems, depending on what that individual maintainer feels is
> the most important and what they want to spend time on.
>
> The point of this bug is to choose a default init system. With most of
> those choices come obvious benefits if we add native support for that init
> system to our packaging. That doesn't mean anyone is obligated to do so.
> It does mean that they shouldn't stand in the way of other people doing
> so.
>
> Some packages are going to be converted to native support for the default
> init system quickly, some slowly, and different contributors will use
> different approaches. That's fine.
Why do you want Debian to support multiple init systems in the first place?
See also below.
> > The following are two quite different options:
> > 1. support multiple init systems since the non-Linux ports are core
> > functionality of Debian
> > 2. support multiple init systems, without considering the non-Linux
> > ports to be core functionality of Debian that has to be protected
>
> > One major reason for people supporting multiple init systems is to allow
> > Debian to keep the non-Linux ports.[2] So they want 1., but might be
> > very surprised if it turns out what they actually got with their vote
> > was 2., and that the non-Linux ports might anyway die in jessie+1.[3]
>
> > And this does matter also since supporting multiple init systems will
> > be a lot more work than a one-time switch from sysvinit to a successor.
>
> I understand what you're saying, I think, and I believe it's the point of
> wording that Ian and I have been discussing: what are we requiring
> maintainers to do when patches are submitted for a non-default init
> system? I think I already said what my position on that is. People
> should not get in the way of other people's work if possible. And
> obviously for jessie people shouldn't drop sysvinit scripts. I don't know
> if we're going to be able to decide right now if people will be able to
> drop sysvinit scripts post-jessie. I think it may be better to wait and
> see what the landscape looks like then.
>
> I think this is a different question than dependencies on logind, because
> in that case we're dealing with upstream decisions to move strongly in a
> particular direction. That's much different than most of the issues we'll
> run into with multiple init systems, where the configuration for different
> init systems is largely independent.
>
> Hopefully, logind will continue to work without systemd and people will
> volunteer to maintain the necessary packaging for that configuration, and
> none of this will be a problem.
I think you missed my point.
Assume a CTTE member wants that Debian does continue to have non-Linux
ports, and therefore wants Debian to make the extra efforts for
supporting a second init system besides systemd.
What level of support (if any) would that guarantee for Debian's ports
to non-Linux kernels?
Or more generally speaking:
Supporting multiple init systems in the packages as well as all use
cases like switching the init system of a running system will be a big
effort from both init system maintainers and maintainers maintaining
packages with init scripts.
What are the goal(s) you want to achieve with forcing the big additional
effort for supporting multiple init systems on Debian maintainers?
And is that additional effort well-spent?
Will these goal(s) be reached?
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Reply to: