Hi, On Mon, Dec 25, 2017 at 06:27:21PM -0800, Russ Allbery wrote: > Ian Jackson <ijack...@chiark.greenend.org.uk> writes: > > Sean Whitton writes: > > >> 2. Do we need to include any text saying *why* the /etc/default practice > >> is a bad idea? I couldn't come up with a succinct way to state it. > >> In general, I think we can err on the side of not including the text, > >> since we have policy bugs that document the reasons. > > > How about this text: > > > Setting a value in /etc/default/PACKAGE is nowadays troublesome > > because supporting that pattern is very hard due to inflexibility in > > systemd, which is usually the default init system.
I don't find anything about the above text to be true. > > > This also makes it clear that this pattern is perfectly fine if for > > any reason the package does not support systemd. > > I don't really agree with this -- I've disliked this approach (and there > were debian-devel threads against it) from long before systemd was > written. The explanation I'd give is that: While I have several other things I find bad about the /etc/default/foo anti-pattern I think the below text is short and clear that it should serve well as one warning against it, thus... > > Setting a flag in /etc/default/PACKAGE hides from the init system > whether or not the daemon should actually be started, which leads to > inconsistent and confusing behavior: ``service <package> start`` may > return success but not start the service, services with a dependency > on this service will be started even though the service isn't running, > and init system status commands may incorrectly claim that the service > was started. Seconded. Regards, Andreas Henriksson
