On Ma, 18 nov 14, 23:12:48, Miles Fidelman wrote:
I still don't think I'm seeing your point. Mail servers, and servers in
general need to be initialized, usually rely on the o/s init system, and
generally come packaged with a collection of init and utility scripts. To
date, every single major server we rely on, for a relatively standard
collection of web, mail, list, and database servers comes stock with ONLY
sysvinit scripts.
To me, that's "caring" about the init system. Can you elaborate on what you
mean by "don't care?"
...
Again, this seems like a backwards perspective. When I put on my product
manager's hat (which I've done at one time in my life), from a developer's
point of view, one generally tries to develop for cross-platform
compatibility. Having to package, or be packaged for a specific environment
is a major inconvenience - especially when said packaging relies on human
beings. From an upstream point of view, the goal is to develop for the
least-common-denominator that's supported across the broadest range
platforms used by one's target users.
You've answered your own question. Currently sysv *is* the least common
denominator.
From an upstream perspective, increased use of systemd, just makes lives
more difficult - once can no longer count on simply including a set of
sysvinit scripts with confidence that they'll just work. At a minimum, they
have to start worrying about incompatibilities between their init scripts
and systemd's implementation of sysvinit.
Assuming there are any.
Beyond that, they have to either
rely on packagers, or start including systemd service files. That just
strikes me as a less desirable situation - more things to go wrong, more
people and steps in the delivery chain.
Service files are incredibly easy to write *and* they already provide a
sysvinit script, so it's not like their software is unusable on systemd
unless they provide one.
As packages in Debian will gain .service files (in addition to sysvinit
scripts) I expect at least a large portion of these to be submitted
upstream, as any diligent Debian package maintainer should do, so you'll
see more and more of them, at least for active upstream/packager
combinations.
Why do the work when the distributions can do it for you? ;)