Public SourceMage Discussion List

[Jeremy Blosser <jblosser-smgl AT firinn.org>]

On Feb 28, Arwed von Merkatz [v.merkatz AT gmx.net] wrote:
> 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?

Yes, if we don't mind doing things in an odd order, we could just leave
init.d and sorcery support for it alone and add other things beside it,
with or without script support.  In this case if you kept using simpleinit
you'd keep using the existing framework (for now), otherwise your own
stuff.  I don't know if we want to push it that way to a stable grimoire
but maybe it's a place to test from.  A fully supported version of this
really has to have the init hanlding out of sorcery at some point, I think.

We probably need more thought on changing the default way we handle
recommended and essential init scripts before doing something like that, we
don't want to be disruptive to users with this where we can avoid it.

> > 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.

It's true, though there is probably a (future) option c, to keep them
organized per-spell but not in the grimoire itself.

Attachment: pgp45GOXOsWpg.pgp
Description: PGP signature