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

Re: init-select



On Fri, Jan 3, 2014 at 1:29 PM, Gaudenz Steinlin wrote:
> Michael Gilbert <mgilbert@debian.org> writes:
>
>> On Fri, Jan 3, 2014 at 11:00 AM, Cyril Brulebois <kibi@debian.org> wrote:
>>> Michael Gilbert <mgilbert@debian.org> (2014-01-03):
>>>> It is often far more ideal when the TC chooses to not act.  TC action
>>>> means that the project is somehow dysfunctional.
>>>>
>>>> init-select is a very simple technical solution to a very large social
>>>> problem.
>>>
>>> Having to pick an init system is *not* a social problem.
>>
>> All TC decisions are attempts at the resolution of social problems.
>> They only consider issues that involve the social disagreement between
>> at least two people.  The fact that the disagreement is happens to be
>> over a technical topic does not eliminate the social aspect.
>>
>>> Trying to support several init systems is *not* in the best interest of
>>> a distribution. Having a fully functional one (and a transition from the
>>> former if it's different) is what we need to work on.
>>
>> Following that logic, supporting multiple packaging helpers, desktop
>> environments, text editors, compilers, kernels, so on and so on are
>> also *not* in the best interest of a distribution.  Let's pick the
>> most functional ones, that is what we need to work on.
>
> As Cyril already said these are false analogies. Supporting multiple
> packageing helpers does not place a burden on maintainers that only use
> one of them. It's also invisible to users. Similar arguments can be made
> for your other examples. On the other hand supporting several init
> systems places a burden onto every daemon maintainer. Every init system
> is only usefull if it's supported by all packages.

So, somehow I think this keeps getting misunderstood, or maybe not
contemplated at a deeper level.

Support for multiple inits means each island in debian gets to choose
the init that suites them best.  gnome and kde lands can choose
systemd since it enables them to be closest to upstream.  kfreebsd,
hurd, xfce, and whatever else lands can choose upstart due to is
portability, so on and so forth.

Ultimately, debian is going to have multiple inits.  It is simple
matter of fact.  gnome will need systemd.  kfreebsd needs something
more portable.  Let's think about how we get to the state where we
support that dynamism in a user-friendly manner.

> The option of just useing the init script compatibility layer that most
> (all) init systems currently provide is IMO just not an option because
> it does not let us use most of the benefits of the newer systems. It's
> just sysv-init in new cloths.

My arguments have never been for that.

Best wishes,
Mike


Reply to: