Le 18/06/2015 11:29, Daniel Reurich a écrit :
On 18/06/15 10:43, Steve Litt wrote:
On Wed, 17 Jun 2015 21:27:21 +0200
Anto <arya...@chello.at> 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??


This is the normal way of implementing this kind of multiple alternative dependencies in Debian, AFAIU. The only reason I did not advocate this before is that it would bring in a bunch of new packages each containing only one small file. But this might not be a big deal after all, considering it solves the problem completely, allows to get rid of the irritating systemd service files, and treats all other init systems equally.

    I support this idea.
                                    Didier


_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Reply via email to