On 28/02/12 11:08, Riku Voipio wrote:
> What is more important is to provide the
> infrastructure to avoid the need of scripting in first place. Like in upstart
> where there are handy stanzas like umask, env, nice, limit, and so on.
This is the reason I like systemd and Upstart better than sysvinit: they
make common init-script things less imperative and more declarative.
Compare with the difference between traditional debian/rules and the
style encouraged by dh and cdbs, between a plain Makefile and Automake,
or for that matter, between a shell script and a Makefile; if you can do
common things by just saying what you want done, the common things
become simpler and more likely to be right, and the special cases that
still need imperative code are much more visible without all the
distracting boilerplate. You can go straight from a quick glance at the
file to "here are the two things that are unusual about this package".
(I think Debian could benefit from declarative versions of some of the
more common tasks for maintainer scripts, too: "add a user for this
daemon", "deal with this obsolete conffile", and so on.
dpkg-maintscript-helper seems like a step in that direction.)
>> in part because there's a weird
>> view in the systemd community that these jobs belong upstream
Turning that around: why is this weird? Why would they belong upstream
any less than, say, the build system?
I think the main reason init scripts can't be upstream is because
they're imperative, and many of the things they do rely on
distro-specific features. The "API" provided by sysvinit itself is
extremely limited - "I'll run your init script with these arguments at
appropriate times" - and the init script has to piece together the
desired behaviour from helper tools. For instance, Debian sysvinit
scripts usually use start-stop-daemon, which upstreams can't use if they
care about portability to Fedora or whatever.
systemd and Upstart represent opportunities to get away from that: every
systemd unit or Upstart job can rely on being able to do most of the
common things needed for daemons (daemonizing, setting umask, going into
a chroot, creating transient directories in /run, ...), because they're
features of systemd or Upstart, and don't need anything
distribution-specific beyond the init system itself.
Upstreams might not know how to get the things their daemon needs from
every possible distribution's init helpers (imperative), but they do
know what their daemon needs (declarative). In a systemd unit or an
upstart job, they can mostly just ask for it. If a distribution needs to
patch the unit/job (perhaps to comply with Debian Policy), that's not
conceptually very different from patching the default configuration, or
the daemon itself, and we already know how to do those.
The upstream git repository for dbus does in fact contain two init
scripts: one for Red Hat, and one for Slackware. They're not the same
(the Red Hat one uses daemon(8), whereas the Slackware one relies on
dbus-daemon to daemonize itself), and neither of them is the same as the
one in Debian (which uses start-stop-daemon). The differences are
necessary given the constraints of sysvinit and what's in each distro,
but at the same time they seem essentially pointless, given that they're
in code which, under systemd or Upstart, shouldn't need to exist at all...
S
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f4cc596.2090...@debian.org
