On Fri, Apr 06, 2007 at 07:10:09PM +0530, Rahul Sundaram wrote:
Patrice Dumas wrote:
>You cannot say that for packagers. Packagers may be interested in that
>work. If we forbid new init systems we prevent interested people to do
Are you suggesting that all packagers would be interested in providing
alternative versions of the required init scripts for all different init
Not all, but those that appear to be popular. But without competition
you cannot know which one is the most popular.
>Why? If people are interested, they will make it scale.
The problem happens when people are not interested. We would end up
having init script systems which don't work properly because the
packages dont provide init scripts except for the default init script
system. When end users find more such packages in the repository (which
do not know is experimental), the level of trust on the quality of the
repository goes down. More choices without proper integration and
testing is bad.
I may be wrong, but I don't think that any user will chose another init
system than the default init system unknowingly. Maybe we could require
for alternate packages that the user edits a file by hand and in this
file there should be something like
# beware, this is not the default init system.
But I don't think the users have expectations about non-default init
systems. If they have wrong expectations, don't do proper investigation
before changing such an important piece of fedora from the default,
change defaults without being knowledgable enough, I don't think these
are users we should care that much about. In any case they will
certainly be free riders, if not worse.
The question here is: What do you propose to guarantee better
integration for all the different init scripts?
The critical difference between a package like the window manager and
alternative init systems is that with window managers integration is
centralized and can be done via proper generation of menus within the
We could have guidelines explaining that the only required system is
the default init. Then we could also provide explanation on how to
integrate each of the init system shipped. It could even be a
requirement for the inclusion in fedora that the maintainer adds a
guideline on te wiki with hints on integration.
With init systems, thousands of packages have to provide alternative
versions of all their init scripts.
I trust in the free software community to provide them for a new init
system if the new init sysem is better or just different, and there is
no entry barrier, like an init system not being packaged in big distros.
We have to
>accept new stuff, otherwise it won't get off. For example, for init
>systems, if we say 'this system is too new, it needs new init
>files/scripts' it will never get in because packagers and upstreams
>potentially interested will say 'this system is not packaged it is
>a waste of time to get interested in it'.
If the goal here is just to experiment and ultimately find the "optimal"
init system (within the constraints that nothing is optimal for
everyone), the solution there is provide the alternative init system
only for the development branch which helps packagers integrate with it
and testers test it and provide feedback while not disrupting the end
users and then only provide a single init system for the stable branches.
Having them in the development branch would be a must in my opinion. And
for stable branch stable enough and widely enough covered init systems
should be accepted. Maybe this could be a guideline.
Trust is not a black and white thing. Neither it is always a question
trust. If we can trust everyone we don't require ACL's in any packages.
We have several cross checks in place, processes and guidelines
precisely because we *cannot* trust all contributors all the time. As we
scale to more contributors expect such processes to *increase*.
Ok, we could have guidelines, like what I suggest above, but just saying
we use only one init system is wrong.