[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: enable/disable flags in /etc/default

(Cross-posting to d-d-games for discussion of the Quake III-based games)

On Tue, 01 Mar 2011 at 15:20:52 -0800, Russ Allbery wrote:
> Speaking as someone who has a few of the DONT_NOT_DISABLE_SERVICE
> variables in some of my packages

Speaking as another implementor of similar variables: I added them in
openarena-server, quake3-server and tremulous-server (game dedicated servers),
with the servers disabled by default, for these reasons:

* openarena currently Depends: openarena-server for common game logic that
  both need; in principle I could add a 5MB openarena-common and make
  openarena-server only contain scripts, or add an openarena-server-run
  only containing the init script, but I didn't really fancy another trip
  through the NEW queue...

* running a Quake III (-based) server from an init script is somewhat less
  capable than running it in screen from a cron @reboot job or something (which
  is documented as an alternative in README.Debian), since you lose the
  ability for an admin to enter console commands in the running server

* I believe it's reasonably common to run several server instances on the
  same machine (e.g. for different game types or map cycles), which isn't at
  all straightforward from an init script

The other good option I've seen for packages where the init script isn't
necessarily the preferred way to run the server is to split the package,
so the server binary and supporting files are in one binary package (e.g.
dnsmasq-base, git-daemon, mysql-server-core-5.1) and the init glue is in
another (dnsmasq, git-daemon-run, mysql-server-5.1).

In that arrangment, alternative setups (dnsmasq run internally by libvirt-bin,
a git-daemon for occasional use run from inetd, mysql run internally by KDE)
can depend on the package containing the actual server, and not the one with
the init scripts. This does lead to proliferation of tiny packages and a
larger Packages file, though...


Reply to: