Re: Upstart and sysvinit in packages - Policy needed

[Tollef Fog Heen <tfheen@err.no>]

]] Henrique de Moraes Holschuh 

| On Mon, 14 Feb 2011, Tollef Fog Heen wrote:
| > That would mean limiting each init system to the limitations of the most
| > limited init system, which would be a sad state of affairs.  Also, I
| 
| Yes.  So, we also have to set where we want the low bar.

I'd rather prefer a solution where we either choose a single more
capable init system going forward or we say that any init script system
must support sysvinit scripts as well as having native jobs (be upstart
or systemd) being able to mask sysvinit jobs of the same name.  This
would allow for improvements without being kept back to the extent we
are today.

| > don't believe there's a 1:1 correspondence between the semantics of all
| > the different init systems, making this a very hard if not impossible
| > job.
| 
| Basically, anything that is not capable of doing _at least_ all that sysv-rc
| can do is still missing required features.

Agreed.  Do we know which, if any, are at that level?

| We must first get to the point where the sysv-rc/startpar combination IS the
| most limited initsystem (removing or fixing anything that is actually more
| limited than sysv-rc+startpar).

Must we?

I'd like to get rid of the solutions that no longer fit, but at the same
time, having to first remove whatever solutions exist today seems
unnecessary for deciding on the road forward.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are