Rainer Weikusat wrote:
> Miles Fidelman <mfidelman@???> writes:
>> Rainer Weikusat wrote:
>>> Miles Fidelman <mfidelman@???> 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