:: Re: [DNG] Packages aren't the only …
Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: Steve Litt
Ημερομηνία:  
Προς: dng
Αντικείμενο: Re: [DNG] Packages aren't the only path to alternate inits
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.

SteveT

Steve Litt
June 2015 featured book: The Key to Everyday Excellence
http://www.troubleshooters.com/key