On Wed, Oct 30, 2013 at 06:18:29PM -0700, Russ Allbery wrote:
> I suspect you and I have a root disagreement over the utility of exposing
> some of those degrees of freedom to every init script author, but if you
> have some more specific examples of policy that you wanted to change but
> couldn't, I'd be interested in examples.
It's not necessarily the init script author who might want the degrees
of freedom, but the local system administrator.
The most basic is the idea that whether you can control (via shell
scrpit fragments) whether or not a service should start at all, and
what options or environments should be enabled by pasing some file.
The fact that we can put that sort of thing in configuration files
such as /etc/default/*, for example.
Yes, yes, you can do this via if you use system V init scripts scripts
in backwards compatibility mode, but you've argued that we should be
moving briskly away from that. In which case system administrators
will need to hand-edit the services files by hand, which will no doubt
increase the chances of conflicts at package upgrade time, compared to
if the configuration options were isolated away in files such as
/etc/default/rsync (for example).
> I realize that
> the local administrator may have other goals, and they should have ways of
> achieving them, but both systemd and upstart support running SysV init
> scripts for those cases.
If the package does not ship a SysV init script (which is your ideal
long-term outcome), that may not be very practical option for a system
adminsitrator who may need to recreate a SysV init script, especially
if the service file is rather complicated, or is using some of the
more advanced feature of systemd/upstart.
- Ted
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
