-upstart subpackage vs tranditional initscripts

[Jeff Spaleta]

On Wed, Jun 2, 2010 at 5:21 AM, Patrice Dumas <pertusus at free.fr> wrote:
> That being said, it seems that the new init system, systemd is already in
> the pipe. Doing a policy for an obsolete technology may be some time
> lost. Maybe even better would be preparing a policy for systemd scripts
> than doing a policy for upstart vs sysvinit.


The only issue I really see is the high priority of the upstart
config. Is that deliberately or is that just how it works out because
of the package naming which influences the yum depresolution scoring.
Whatever the reason I'm

The existence of the subpackages aren't strictly a problem
necessarily. But they definitely complicate things....if we want to do
more than just ensure the default init system config is installed on
the system.  Even if systemd becomes the default, I doubt upstart is
going to disappear from the repository. Some people are going to want
to use it and some maintainers will support it with native configs.
The question is how do we make sure the correct init file that is
compatible with the init system in use on the system is installed.

Assuming moving forward a maintainer has the option to support
sysinitv, upstart and systemd, what can be done to make sure the
correct init configuration is loaded on the system? Other than
including all the configs in the base package..I'm not sure I have a
useful suggestion for a solution to selection. And even then, if you
have the sysinitv installed side-by-side with the native upstart or
systemd config is that going to cause a conflict?



-jef