Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Serge,
I'm in the favor of having a try with OpenRC, and see what we can do,
but here, your post is a bit naive at least in some cases. Let me
explain why.
On 09/05/2012 11:47 AM, Serge wrote:
>> I don't see how these people help Debian if they start pushing their
>> own solution instead of helping to improve what is already there.
>>
> I thought it's obvious:
> * someone packages a new tool (+1 package, +1 maintainer)
>
In this case, it's 1 package, many maintainers.
> * more packages in debian means more users
>
No. Not for sure.
> * more users means more developers
>
No. Not for sure.
> * more developers and maintainers means better debian
>
It all depends on what these maintainers do.
> Anyway, I *guess* I understand your point. You afraid that *if* this new
> `openrc` is accepted
There's no "if" here. I don't think anyone has the power to forbid such
an upload.
The problem is to decide if we should support OpenRC archive wide, and
that's
the debate, it's not just about uploading or not (eg: OpenRC isn't a
leaf package).
> *and* widely used in debian
That's another story. We aren't there yet, we don't even have a working
package yet.
> *and* other package start
> depending on it badly *and* its maintainer will abandon it, then we may
> have a problem.
I don't see why this would happen more than with any other stuff.
So why are we even considering it? It doesn't make sense.
> So between two options:
> 1. Someone packages `openrc` and starts maintaining it. Being a maintainer
> he may (or may not) help other packages as well.
>
Again, more than one person is interested in such work.
> But the problem is — we don't have that choice. What we really have is:
> 1. Someone packages `openrc` in debian and starts maintaining it. Being
> a maintainer he may (or may not) help other packages as well.
> 2. Someone goes to launchpad/github/some-private-repo and maintains
> `openrc` there for himself and some friends.
> Having such a choice I would prefer #1. And you?
>
"Help" isn't enough. If we decide that OpenRC should be supported archive
wide (which decision, IMO, shouldn't be discuss now), then there's thousands
of packages affected.
Of course, if we decide to support OpenRC, help and documentation will be
mandatory. But not enough.
> I was trying to use some common sense (i.e. explaining that it's rude to
> say to people what they should do, it scares them away which means less
> maintainers which is bad for debian), but if you want to stick to rules,
> then `openrc` should be, no, it MUST be in debian repository, since at
> least some users asked for it and "Our priorities are our users and free
> software", right? Also those rules don't allow anybody to decide what
> package I must work on, right?
>
That's correct, anyone can work on what he wants. Though some
decided to skip one step and talk about what should be the default
when we are far from there.
Also, the problem that has been highlighted was that if OpenRC
comes to Debian, this might give a lot of work for all maintainers
with packages that have init script. In fact, this is the same situation
as for systemd. And we don't want to duplicate this work. I do agree
with this, but I don't think we are there yet. What I asked, is to let
us try, and see where it leads...
>> I'm not saying I wouldn't trust your words, but you cannot seriously
>> promise you will always be there to take care of OpenRC if you're the
>> only maintainer.
>>
> Sure, I can't. Anything may happen. And noone can. That's why "being about
> choice" is a good thing. If for some reason debian supported only `systemd`
> and tomorrow upstream announces "forget systemd it won't be supported any
> more, we've just developed a new kernel-based init system with GNOME4
> integrated into it, and being kernel-based it is lightning fast", then we'll
> have a problem.
That's exactly the problem. We have no way to predict whatever
will be upstream's decision for systemd. That's in fact, one of
the reasons I'd be interested in contributing to the OpenRC
packaging (I still hope to find more time with Patrick on that...).
Thomas
Reply to: