On Thu, 2007-04-05 at 10:57 -0400, Jesse Keating wrote:
On Thursday 05 April 2007 07:38:26 Patrice Dumas wrote:
> I think this is a very wrong direction for fedora. Free software is
> about choice. And also being able to test innovative technologies.
> The default init system should be privileged, but all should be present,
> such that power users are able to test and use them. The directions that
> developers and packagers want to follow, how they spend their time is
> their business. If there are enough people interested in new init
> systems, lets have them. As a project we have to watch out the packaging
> quality, the integration in the distro and have good defaults. Our
> mandate should not to be in the way of initiatives.
At the same time, I don't want to stamp the Fedora name on something that has
6 half working init system choices, but none that work fully. It's the same
reason we don't ship 6 different kernel compiles (other than xen or no xen,
smp or no smp, these are because one won't work across all hardware
sets/systems). Certain things in the distro have to be rock solid, the init
system is one of those.
Now, I'm all for seeing development happen and initiatives. You can create a
secondary repo around trying out a new init system. I just don't want to see
them clutter up the main repos that every user gets access to.
Are we going to unmerge Extras and Core for F8? ;-)
More seriously, I agree with Patrice that Fedora has a mandate to ship
new and in-development things for users to try if they don't conflict
with core components. Since init systems can be parallel installed, I
think that they belong in the Fedora repository.
One thing that Patrice isn't stressing, however, is that using a
different initsystem usually requires writing new initscripts. So we
need to have some policy about initscripts in Fedora. Something like:
"""
Packages that are to be started at system startup must provide an
initscript for the default Fedora init system. Here are <link>details
on writing an initscript</link> for SysVinit, our current default. In
addition, other packagers may be interested in providing initscripts for
alternate init systems. When this happens, the package should install
the alternate init script [Guidance on how].
"""
This is not a complete policy. How is a very big question. Subpackage?
The same package that provides SysVinit? Who has responsibility for
submitting the alternate init scripts to upstream? Should there be a
SIG that helps add support for different init systems?
-Toshio