-upstart subpackage vs tranditional initscripts

[Jeff Spaleta]

On Wed, Jun 2, 2010 at 10:43 AM, Michael Cronenworth <mike at cchtml.com> wrote:
> Lennart Poettering wrote:
> If you can make everyone move away from sysv to something else, then by
> all means I'll do my best to aid in patches, but I don't have much
> confidence since everything that has been said about systemd has been
> said of upstart a few years ago. Instead of reinventing the wheel time
> and time again, there are other features that deserve attention.

I think its really premature to talk about any situation where we
forcibly drop sysv compatibility. Way way premature. It may never be
possible in reality.

You'll note that so far we haven't actually encouraged the use of
upstart native scripts. It's difficult to see how one could lose
confidence based on our upstart experience when the reality is we've
barely moved away from sysv. We have just a few native upstart
scripts. We've essentially been running upstart in sysv compatibility
mode putting nearly zero demands on casual packagers to do anything
with regard to making init scripts native.  That's actually part of
the problem with upstart, its lingered for so long in a sort of
compatibility mode that its not clear what the realizable benefits
actually are.  I don't think I've seen any quantitative analysis of
the impact of upstart native configs in any real deployment scenario.
This is one of the things I'm looking forward to seeing in future
systemd discussion.

I fully expect that systemd integration to start in a sysv
compatibility mode..but with real native configuration usage up front
in enough components for us to work with so we can all get a taste of
the impact.  I fully anticipate systemd sysv compatibility mode as a
priority to make sure no casual maintainer is forced to build native
configs out of the gate on their own. i fully expect, and trust, that
the people who really grok systemd are going to be heavily involved
with ensuring the first set of native systemd services are exemplary
examples for the rest of us to follow...and to do our best to break.
If the wins are obvious, then work on native configs will snowball
based on a desire to maximize the achievable benefits.

All Lennart is saying is that systemd will have a better experience
for packagers while we are navigating the switch-over period. We won't
have to play games with subpackages..we ship both sysv and native
systemd in the same package.  Eventually Fedora project leadership may
decide that native configs will be required for new packages or what
not as a policy decision...but that discussion is a long long long way
off.  Let's just see if we can actually get systemd in early into F14
testing, relying on sysv compatibility primarily so we can feel
comfortable that its been well tested.

-jef