On 03/05/16 21:43, KatolaZ wrote:
> On Tue, May 03, 2016 at 09:24:42PM +1200, Daniel Reurich wrote:
>
> [cut]
>
>>
>> Absolutely, but for the average user, having /etc/init.d and
>> /etc/openrc and /etc/wtf all there when using sysvinit (and not
>> changing between init systems) is only going to lead to confusion.
>> Being able to have them only installed when the init system is
>> installed reduces the cruft left around - and the only way to do
>> that is with triggers ala init-system-helpers and deb-helper shim
>> for each init that's added to a package.
>>
>
> Agreed. But still, it would me much easier to maintain the whole
> mess if each init system is isolated from the others, with no
> interactions whatsoever. Different inits, separate scripts, separate
> directories.

That's what I'm saying also - keep them separate but only install those
parts when their respective init systems are installed.
>
>> The bonus is that each init system can be implemented independently
>> and the service packages have support built-in as people wanting
>> their fav init system get it added in to the package. This will in
>> most cases be a small patch adding the necessary init scripts and
>> adding dh-<init-system> into debian/rules. No extra cruft will be
>> installed on the end users system unless the user installs that
>> init system.
>>
>
> This might become a bit of a mess, if I understood correctly, since
> we would have to maintain either a package of scripts for each init
> system, or thousands packages like "apache-scripts-sysv",
> "apache-scripts-openrc", "apache-scripts-wtf".....
>
No. The init scripts for all inits go directly in the package - apache.
But they should be deployed to (or removed from) the filesystem by a
dpkg-trigger that is tripped by the installation or removal of the
respective init-system to which those packages belong.

> Why we don't just ship the init scripts for each system with the
> corresponding service, install them "somewhere else" (e.g.,
> /var/cache/sysvinit, /var/cache/openrc, /var/cache/wtf, as has been
> already suggested by others)

Yes I agree about this too!

> and then copy (or symlink) the corresponding directory in /etc/ only
> when the user selects "wtf" as init system?
No this is wrong.. because the user will have all this cruft installed
for all possible init systems which will be confusing.

The dpkg-triggers way means that only when "wtf" init is installed does
dpkg-trigger install the scripts for "wtf" from each services package
into /etc/wtf.

> This could be managed much more easily by update-alternatives, which
> has just to update two symlinks, e.g. he one corresponding to
> /sbin/init and the one corresponding to it's bloody scripts
> directory

I'm not sure the first is best managed that way and the second is
entirely superfluous as each respective init should point to it's own
binary and directory of init scripts directly.

I'd prefer to have a <initsystem>-base and <initsystem> package with:

<initsystem>-base being installed/removed triggering deployment/removal
of all the service scripts (and any work arounds for services without
scripts for that specific init system)

<initsystem> providing the init binary and pre-depending on
<initsystem>-base (so <initsystem> can't be installed without
<initsystem>-base, and <initsystem>-base can't be installed without
first changing the initsystem. As already is the case <initsystem>
depends on the package "init" which is a meta-package that enforces one
<initsystem> to be installed and also sets the default <initsystem>

Anyway this is pie in the skie talk until we have a final release out.

Regards,
    Daniel.

--
Daniel Reurich
Centurion Computer Technology (2005) Ltd.
021 797 722