Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Init_Plans Project

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Jeremy Blosser <jblosser-smgl AT firinn.org>
  • To: sm-discuss <sm-discuss AT lists.ibiblio.org>
  • Subject: Re: [SM-Discuss] Init_Plans Project
  • Date: Wed, 28 Feb 2007 12:11:12 -0600

Sorry that one was getting too long, now let's make it practical:

On Feb 28, Jeremy Blosser [jblosser-smgl AT firinn.org] wrote:
> On Feb 28, "Andra?? 'ruskie' Levstik" [ruskie AT mages.ath.cx] wrote:
> > http://wiki.sourcemage.org/Init_Plans
> >
> > It's based on the discussions that happened on irc. The overall consensus
> > is that we should switch to a more mainstream, maintained and stable init
> > system. This is a long term plan so don't expect any serious work being
> > done
> > on it in the next 6 months.
> >
> > We do have a green light from our project lead to start researching
> > various init systems so that we could in the end make an informed
> > decision about which one we would like.

So if a group of you want to work on the init problems, these are what I
would prefer as the goals:

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

1) Figure out if there is a stable, maintained /sbin/init out there we can
mostly drop in to replace our current one, with minimal disruption to
our scripts. I would *like* a quick timeframe on this, since we're not
looking at changing a lot and we want to get past this. As long as it's
short term I don't care much what system it is as long as it's better
maintained than simpleinit and doesn't give us its own baggage.

> 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.
>
> Whichever of these we'd use, we'd make it so the migration just ends
> someone in the place they'd be if we'd had this all along and they'd chosen
> simpleinit and installed the scripts provided. Then if they want to
> migrate from there, they can.

2) Figure out how to get us here. First step would be to get simpleinit
working in this kind of framework, which includes fixing bug 13196 but
is relatively simple beyond that. Second step is getting another system
in there to demonstrate it works to move between them. Beyond that it's
other people adding spells and scripts for their preferred system.

> If we get there I think we have a solid base that fits our philosophy.
> *Then* if people want to look at doing #2 above by creating a new component
> or tool that provides a better way to manage the different types of
> scripts, I think they have somewhere to work from, and the distro still has
> somewhere solid to fall back to if it doesn't work out.

3) If we get this far, we'll have a lot more to talk about...

Attachment: pgpVKzPmcVUMm.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page