Services that can start by default policy feedback

[Lennart Poettering]

On Thu, 24.02.11 15:04, Matthew Garrett (mjg59 at srcf.ucam.org) wrote:

> 
> On Thu, Feb 24, 2011 at 09:44:19AM -0500, Colin Walters wrote:
> > On Wed, Feb 23, 2011 at 1:56 PM, Kevin Fenzi <kevin at scrye.com> wrote:
> > > Greetings.
> > >
> > > FESCo is looking at the question of what services can start by default
> > > (ie, you install something and it's set to start automatically next
> > > time you boot up).
> > 
> > Honestly I think it'd be conceptually a lot simpler if all services
> > didn't start on RPM installation, period.  Specific ones that we want
> > enabled by default in a desktop install could simply be turned on in
> > the kickstart file.
> 
> We considered that option, but it's not just about the desktop install - 
> you need a default set for a default install, or the entire world is 
> going to set fire to you because cron isn't there by default any more. 
> And once you've got a default set for the default install, why not just 
> do it at the package level and ensure some level of consistency?

Related to this:

Some people have been asking us to extend the systemd unit file header
to include information about whether a service should be on or off by
default (Michal!), like chkconfig had it. But after thinking about this
we came to the conclusion that this information is not specific to
services at all, but to the distro image you install, and hence has no
place in the unit files. Ideally unit files are shipped along the
upstream sources, and whether a service is enabled by default is not an
upstream decision, but genuinely one not only of the distro but by the
particular distro "profile" installed. Hence the place to encode this
information is not the upstream shipped unit files and not packaging
spec files, but other distro specific list.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.