Rainer Weikusat wrote:
Miles Fidelman <mfidel...@meetinghouse.net> writes:
Rainer Weikusat wrote:
Miles Fidelman <mfidel...@meetinghouse.net> writes:
Alexey Rochev wrote
*Date: *2015-08-05 07:29 -400
*To: *dng
*Subject: *[DNG] Init scripts in packages
Currently Debian packages contains both systemd units and init scripts.
However, Debian developers refused to support several init
systems. So it's
only a matter of time when they remove init scripts from packages.
What will Devuan developers do when it happens? We can use sysvinit and
Devuan because these init scripts exist.
It occurs to me that nobody raised the obvious questions:
1. Are we seeing upstream developers shipping systemd scripts, or
systemd scripts w/o sysv init scripts? I'm not sure I have.
2. What the heck are Debian developers (packagers, actually), doing
removing init scripts?
There's an answer to that and it's "it doesn't matter" (I tried to point
that out in an earlier reply). On the wheezy system I'm using to write
this, 'init scripts' make up 6789 LOC, nobody has the power to make them
disintegrate and I'd be very much surprised if there are more than 2000 LOC
in there which actually do something useful. Actually, I expect
yes. init scripts should be trivial and if they're not, something else
is amiss.
[...]
Right now, init script come from upstream, Debian "developers" (I
really can't bring myself to call a packager a developer) test & tweak
the upstream scripts to fit the Debian environment. If they stop
doing that, someone is going to have to do that for Devuan.
Do they actually come 'from upstream'?
Absolutely. At least for most server code,
tar xvf foo; ./configure; make install
leaves you with running server code, with default configuration (as
tailored by configure), and init scripts
Packagers typically modify those scripts.
Also, to re-iterate this: What an init script needs to do is really only
'start a process'/ 'stop a process'. Most of the other code which crept
in there during the last 15 - 20 years will fall into one of two
categories
1) Never did anything useful
2) Should never have been implemented in this way.
It can be a bit more than that, for example, the sympa mailing list
package consists of multiple programs that are started in order, and
includes
- start (all 4)
- stop (all 4)
- restart (stop, in order; start in order)
- status
Most server scripts do some setup and cleanup. There's also typically a
reload config files option.
This is a non-tempest in a teapot nobody ever really saw.
Worse, if "refuse to support multiple init systems" means that the
Debian packagers start stripping out the init scripts from Debian
packages, those, those packages become useless in Devuan.
Last time I looked, the point of Apache was "it's a web server" and not
"it comes with an init script" so this seems to have been blown somewhat
out of proportion. Even if 'Debian developers' should stop shipping
'init scripts' as part of their packages at some point in time in the
future, this won't cause them to disappear from packages people already
installed. And even in the extremely unlikely case to
$evil_debian_developper invades your computer in the middle of the
night and steals $mission_critical_init_script (this happening
simultaneously on all computers in the world), they'll be trivial to
replace.
Trivial as in, somebody has to do it. The whole point of packaging is
to automate a lot of the routine things involved in installation.
And, because Debian (and presumeably Devuan) don't put stuff in default
locations, packaging involves changing the default locations of things.
Where this leads is that down the road, we either need a full set of
Devuan-specific package maintainers, or everybody is back to compiling
and installing from upstream source.
Miles Fidelman
--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
