Gentoo + Upstart

[Justin Mason]

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.

--j.