Re: Tentative summary of the amendments
On 24 October 2014 13:33, Ansgar Burchardt <ansgar@debian.org> wrote:
> But instead we should take away packages that depend on a features only
> provided by a specific init system (for whatever reason)? Do you think
> we serve users better by taking away options from them?
Sometimes - yes, especially in the long term. We did take away KDE
from our users at one point. We also do not allow packages into the
archive for many different technical and social reasons (patents,
embedded libraries, ...). In the end our users know that *if* the
software passed the scrutiny and got into Debian, then it must be good
(for some definitions of good).
> So, if P has a hard dependency on systemd-as-pid1, why do you want to
> take P away from me? Because people not liking systemd are more
> important than people not caring about it or even being okay with it?
It is not about "people not liking systemd". It is about people using
other init systems. The question is about how strongly do we feel
about supporting this group of users.
> I don't like some software too, but am sometimes required to use it
> without an alternative. Can I demand that I can use packages without
> said software? Like demanding libraries having to provide language
> bindings for at least two languages so I don't have to use PHP[1]? :)
Init system is special because there can be only one active in the
system. If app1 depends on systemd (as PID 1) and app2 depends on
runit (as PID 1) then it becomes impossible to use both apps (without
changing init system and rebooting). Also IMHO init system should be a
user choice and not dictated by other, unrelated, software.
In any case, this is uncharted territory, because (to my knowledge)
until systemd started integrating system level services into init
system itself, applications never depended on particular APIs of init
systems.
We need to make a conscious decision on how to handle that. If we
don't then it is likely that the process will go on as before:
* systemd introduces a great new system level service,
* key apps depend on that service to do great things (and stop working
on all other init systems),
* people using other init systems are sad,
* after a lot of hard work a new ugly hack shows up to patch out or
fake out the new service (making apps kind of work again, but not as
good as before),
* another flamewar/GR is started to stop systemd dependencies breaking
software for other people
* (repeat)
I am sure that there will be several more rounds of these because
systemd has a *lot* of very interesting and useful services coming up
in their plans. I can't wait to use most of them, but at the same time
it sound like they are developed in a tight coupling with systemd
itself thus making all those very useful features unavailable to users
of all other init systems. Like the upcoming wifi management changes -
those sound great, but there doesn't seem to be a reason why it
couldn't have been designed in such way that users of other init
systems could simply call some executable with some params and have
their wifi configured with those tools.
Being the default init system should not be the mandate to
break/rewrite everything else. In fact being the default init system
should bring great responsibility *not* to break stuff.
--
Best regards,
Aigars Mahinovs mailto:aigarius@debian.org
#--------------------------------------------------------------#
| .''`. Debian GNU/Linux (http://www.debian.org) |
| : :' : Latvian Open Source Assoc. (http://www.laka.lv) |
| `. `' Linux Administration and Free Software Consulting |
| `- (http://www.aiteki.com) |
#--------------------------------------------------------------#
Reply to: