On 18/06/15 10:43, Steve Litt wrote:
> On Wed, 17 Jun 2015 21:27:21 +0200
> Anto <aryanto@???> wrote:
>
>>
>>
>> On 17/06/15 17:37, Steve Litt wrote:
>>> Hi all,
>>>
>>> After the recent discussions, I'd like to point out that packages
>>> aren't the ONLY path to alternate inits. I've personally
>>> demonstrated that with SucklessInit+daemontoolsEncore,
>>> SucklessInit+s6, runit, and Epoch, it's quite doable to download,
>>> build, and install these things in parallel to each other.
>>>
>>> I fully endorse the effort to put alternative inits in packages. It
>>> would be wonderful to have, for instance, an Epoch package that
>>> "just works". I also endorse those individuals who go the
>>> out-of-package route.
>>>
>>> Thanks,
>>>
>>> SteveT
>>>
>>> Steve Litt
>>> June 2015 featured book: The Key to Everyday Excellence
>>> http://www.troubleshooters.com/key
>>>
>>
>> Hello Steve,
>>
>> I agree with you that packaging epoch init system is not the only way
>> to have it as alternate init. However, that depends on the type of PC
>> which we would use epoch init system on.
>>
>> What I plan to do is to have epoch init system on a regular PC which
>> I am using everyday. So not on a test PC where I can do a lot of
>> crazy things then just bin the idea if I am not happy and wipe the
>> whole hard disk. On a regular PC, I want to be able to *easily*
>> install and uninstall packages as I normally do, including switch
>> back to sysvinit. And I want epoch init to be able to manage the
>> daemons which might come from those packages, e.g. wicd package to
>> manage my WiFi connection. For this purpose, I think the only way to
>> be able to use epoch init system is to have it as a package,
>> especially on Debian based distros.
>>
>> From what I have gathered and understood so far, I have 4 options to
>> use epoch init system:
>>
>> 1. As I want to use Devuan, I have to patch all packages containing
>> daemons that I want to use with epoch init configuration, build epoch
>> package according to the packaging rules, compile them and install
>> them as standard package.
>>
>> 2. If I still insisted to use Devuan but I don't want to go through
>> all troubles on option 1, I compile epoch using the upstream build
>> script, manually install the compiled bin files, manually add the
>> daemons init configurations into epoch.conf. Along the time, I will
>> have to manually add epoch init configuration into epoch.conf, for
>> every packages with daemons that I install. And I will have to deal
>> with all issues related to those packages due to the
>> incompatibilities between epoch and sysvinit.
>>
>> 3. I don't want to keep following Debian rules, so I develop my own
>> distro with my own rules and my own package manager. The works for
>> that will possibly be more than for both previous options, but I will
>> have control over everything.
>>
>> 4. Or I just use LFS with epoch init system.
>>
>> Seriously, with my current knowledge and experience, you can be sure
>> that I will fail if I would do any of the first 3 options. So the
>> only feasible option is the last one. But why am I here making noise
>> if I didn't want to use Devuan?
>>
>> So what am I going to do about this now a part from to forget about
>> this and move on? Do you or anyone else have suggestions?
>
>
> Yes. I have a suggestion. I suggest we just start assembling a group of
> Epoch object descriptions for the top 30 most used daemons. Then, as
> people request them of other daemons, we add those. I suggest we keep
> these as a group of scripts, *not* as anything the "upstream" has to
> worry about.
>
> Look how this works: In 3 weeks we can have 30 Epoch daemon object
> recipes. sshd, ntpd, crond, httpd, all the usual suspects. In 3 weeks
> we've satisfied 80% of the people, with no "help" from the "upstreams".
> We let people know that if they need an Epoch object description for a
> given daemon we don't yet support, we'll treat that like a bug report
> and make such a Epoch object description. As time goes on we'll have a
> big library of these things, and people will notice that Epoch object
> descriptions are an order of magnitude easier to understand, and
> therefore to DIY, as sysvinit scripts. Probably easier than systemd
> unit files too, given that I've never heard any person describe how
> systemd actually works.
>
> You can have most of your easy Epoch installation, on Devuan, in 3
> weeks. I have virtual machines, so I can help. It will be fun. And you
> know what? I might just take each of those Epoch object descriptions,
> and make a daemontools/daemontools-encore/runit/s6 run file based on it.
>

I wonder if now is the time to start separating out the init specific
configuration files, initscripts or service files, libraries and
binaries out into separate packages so that any particular init can be
supported without treading on the toes of others. The only issue I can
see with this is the dependency chain can get a bit hairy.

I expect the dependency chain should be something like:
<daemon> depends on: init, <daemon>-sysv-init | <daemon>-epoch-init |
<daemon>-systemd-init | <daemon>-openrc-init | <daemon>-upstart-init

And if each of those <daemon>-*-init packages depended on their
respective init system, and each of those init systems provide the
virtual package "init" (as is the case in Debian and Devuan Jessie),
then apt should be able to work out that when installing <daemon> that
because sysvinit-core is the package providing init that it must also
install <daemon>-sysv-init in order to satisfy the dependency. The
problem is whether changing init systems would result in pulling in the
new <daemon>-*-init dependency required for the new init system.

Thoughts??





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