Re: init script, installed but not activated
On Wed, 2015-10-07 at 19:21 +0200, Marc Haber wrote:
> On Tue, 6 Oct 2015 22:35:38 +0200, Michael Biebl <biebl@debian.org>
> wrote:
> >If your package does not work unconfigured, a better alternative is to
> >check for the existence of a config file.
>
> This, however, prevents you from delivering an all-comments default
> config file in the right place, which makes configuring the package
> harder and non-intuitive.
>
> Checking for a config file with at least one non-comment line in the
> systemd-unit is ugly.
I don't think we have a good, standard, story for how installation,
configuration and enabling of packages that can be used to provide
services *should* work.
Personally, I'd prefer that packages get a default configuration and
services are never enabled on install. However, I get that some/many
people would prefer that debconf ask them enough questions to configure
a package and that the service be enabled by the end of the install.
There might well also be different classes of service with different
levels of config requirements - if you install an RPC portmapper, it's
more likely to be able to DTRT if it tries to configure and enable than,
say, mailscanner. In the middle are services that can ask a few simple
debconf questions and then have a good chance of doing the right thing.
Some services might also be potentially harmful if enabled by the
install process - DHCP servers being a good example.
I think this is something that we should have covered by policy, so a
user knows what to expect when installing a package (e.g. so they know
that they don't need to disconnect the machine from their corporate
network before installing isc-dhcp-server).
It certainly seems to me that a standard default is needed, and that
system-wide configuration of this might be desirable.
Am I missing something? Thoughts?
Cheers,
Nick
--
Nick Phillips / nick.phillips@otago.ac.nz / 03 479 4195
# These statements are mine, not those of the University of Otago
Reply to: