systemd acceptance, packaging guidelines (was Re: systemd and changes)

Matthew Miller mattdm at mattdm.org
Tue Aug 24 15:15:11 UTC 2010


On Tue, Aug 24, 2010 at 08:45:33AM -0400, Matthias Clasen wrote:
> > GENERAL SANITY
> > - Booting a system shall achieve a similar result as booting in upstart:
> > -- The same set of services will be started.
> 
> I don't think this is a requirement on systemd, really. If we make
> changes to the default system configuration to not include a service in
> F14 that was included in F13, that is not a systemd problem. So, I think
> what you really mean here is: systemd will start all services that are
> configured to be included in the default install (and dependencies), but
> no others.

If we're still including upstart as a fallback option, I think it's
reasonable to ask that making that selection doesn't significantly change
what gets started -- *or*, that if it is expected to behave differently, all
ways in which it will be different are clearly documented in the release
notes.

Cases where I think documenting differences is appropriate rather than
requiring identical behavior would be:

  - services which take advantage of fancy new systemd features
  - services which take advantage of any upstartd features which systemd
    does not implement in a similar fashion (if such things exist).
  - services where the end-user has gone out of their way to configure
    upstart in a fancy non-default way.

It'd be *nice* if the last case could automatically work too, but I'm not
expecting magic. So instead, we need to be clear.


> > - The basic syntax of systemd commands shall be frozen for future releases.
> > - The syntax of systemd units shall be frozen for future releases.
> Again, the best we can ask for is backwards compatibility, I think.
> 'Frozen' is entirely too strong for a 2 month old project.

In fact, I think we need some flexibility to change things which turn out to
be sub-optimal once they're out in the real world. Freezing these decisions
too soon is one of the strong arguments for waiting until F15.

-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences


More information about the devel mailing list