Gentoo + Upstart

[Thom May]

* Justin Mason (jm at jmason.org) wrote :
> 
> Michael Biebl writes:
> > 2006/10/18, Sean E. Russell <upstart at ser1.net>:
> > 
> > > On sysvinit, you symlink init scripts into the rc.? directories as S and K
> > > scripts.  On Gentoo, you use 'rc-update add|del' to add and remove init
> > > scripts, and Gentoo handles resolving dependencies to insert the script into
> > > the init sequence in the appropriate place. In Upstart, you place event
> > > scripts into /etc/event.d, and if the appropriate events are generated, the
> > > scripts will be run.  To disable scripts, they are removed from /etc/event.d.
> > >
> > > 0) When a service is disabled, where should the event script be moved to?
> > > Removing it entirely is not a good idea... it can't be easily re-enabled.
> > >
> > > 1) When a package manager installs a package, where should it put the event
> > > script?  On Gentoo, the default behavior when a service is installed is NOT
> > > to automatically enable it.  If you install CUPS, you must
> > > additionally "rc-update add" it to get it to start.  To replicate this
> > > policy, there should be an intermediate place for (disabled) event scripts to
> > > live, and it woludn't be a terrible thing to have an Upstart script that
> > > moves event scripts between the /etc/event.d and <disabled> directories --
> > > something that implements the functionality of "rc-update" and
> > > Redhat's "service".
> > >
> > > Any convenience scripts are secondary, and can be added later; the important
> > > part, I think, is the policy decision about where disabled Upstart scripts
> > > should live.
> > 
> > What about installing the job description files to /usr/lib/upstart/
> > (or /lib/upstart or any other suitable directory).
> > "Activating a service" means creating a symlink to /etc/event.d.
> > I like this idea, because it makes it easy to spot, which services are
> > activated or not (compared to installing all files to /etc/event.d and
> > then disabling the services by editing the files  and setting a
> > "disabled" flag).
> > In addition a tool like "rc-update" would be quite easy to implement
> > because it wouldn't have to parse and write job description files
> > rather than creating (or removing) a mere symlink.
> 
> I quite like the Apache2 on Debian model: sites, including both enabled
> and disabled sets, are described in files (one file per site) in
> '/etc/apache2/sites-available/'.  Sites that are enabled are symlinked
> from '/etc/apache2/sites-enabled/' to the corresponding file in
> sites-available.  To disable a site, rm the /etc/apache2/sites-enabled/
> symlink; to re-enable, create a new symlink.

Oddly enough I'm quite keen on this too, and think this is actually a pretty
reasonable way of ensuring both visibility of configuration scripts (and,
under dpkg, ensures that local modifications are preserved correctly) and
visibility of what is currently enabled.
-Thom