Public SourceMage Discussion List

[Arwed von Merkatz <v.merkatz AT gmx.net>]

On Wed, Feb 28, 2007 at 11:47:32AM -0600, Jeremy Blosser wrote:
[...]
> There has been talk of basically three approaches to init:
> 
> 1) One init system; this produces lots of arguing about what the init needs
>    to do, not surprising considering our philosophy of choice.  This is not
>    who we are and it's not going to get us progress.
> 
> 2) A metainit system, where we provide some kind of template init script
>    instead of one targetted at a specific init system, and then have spells
>    for the different inits we support.  Users pick the one they want and
>    some engine parses the template into the right init script format and
>    installs it.  This has some aspects of an ideal solution but it also
>    requires a lot of work and may still limit us to only some inits
>    supported or a limited type of inits supported (not everything fits a
>    template).
> 
> 3) No init system beyond spells; let the admins figure it out themselves.
>    Just have a spell for each init system someone wants to write a spell
>    for, have them conflict with each other, and make basesystem depend on
>    INIT-SYSTEM.  This is the truest to letting the admin control their
>    system, and doesn't limit us at all in which ones we provide, but it
>    also means potentially automating fewer routine things for people than
>    we do now, and that's controversial.  Most of us probably don't want to
>    write all of our own init scripts, and there's no question that once
>    someone writes some they will probably want to be able to share them.
> 
> These 3 can reasonably seen as a continuum of most distro control to least
> distro control, with #2 as an ideal, given unlimited resources on our end.
> But we don't have unlimited resources, so I think we should make use of all
> 3 in getting from where we are now to a more ideal state.  Right now we are
> on #1.  We may need to move to a different form of #1 to solve the
> short-term problems with simpleinit.  But we shouldn't stay there.

Aren't we rather in the area of #3, except we don't provide spells for
alternative inits right now? We do have scripts that are installed by
the init system itself for core stuff, and do have the RECOMMENDED
mechanism to default to installing some init scripts, but overall the
default is not to install init scripts unless the user wants to.
Adjust our current setup to allow defaulting RECOMMENDED stuff to no
too, add a sysv init spell, and we're pretty much there ;)
Or am I missing something here?

> I personally would want us to move to something like #3, because we can get
> there somewhat quickly, and because it's frankly where we should have
> started from in the first place.  We should have always let people pick
> their own init poison, and added support for managing the different scripts
> later as it was needed and made sense.  I don't want to disrupt users but I
> would like to see us get to this as our base for init.  We can pretty
> easily avoid being disruptive to people if we get a decent script sharing
> mechanism in place, such as:
> 
> a) Having a scripts/ area with each init system that contains all the init
>    scripts people have written that are compatible with that system, so
>    when you eg 'cast bsd-init' you'd get 'Install provided init scripts?"
>    This keeps it with the systems but means people have scripts installed
>    they don't use.
>    
> b) Having the init.d/ dir for each spell contain init scripts for different
>    systems, as people contribute them.  eg init.d/sshd.{simple,sysv,bsd,etc}
>    This lets them only get the ones they use, but means the advocates of
>    given init systems have to touch more spells, and spells potentially get
>    bigger.

I think option b) is better, as init scripts can and do change with
spell versions due to changes in how the programs installed work, so
keeping them with the spells makes that easier. With the scripts in a
central location, they'd need to somehow adapt to the installed version
of their programs.

-- 
Arwed v. Merkatz                              Source Mage GNU/Linux developer
                                                    http://www.sourcemage.org