:: Re: [DNG] Packages aren't the only …
Góra strony
Delete this message
Reply to this message
Autor: Anto
Data:  
Dla: dng
Temat: Re: [DNG] Packages aren't the only path to alternate inits


On 18/06/15 00: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.
>
> SteveT
>
> Steve Litt
> June 2015 featured book: The Key to Everyday Excellence
> http://www.troubleshooters.com/key
>
>


Thanks Steve,

It looks like that you suggested to go for option 2.

I actually tend to go for option 3 especially that I have already
cleaned up more than what Devuan does and recompiled all packages on my
PC that I am using now to write this email. But I have to be realistic
as I need a lot more than that to build a new distro. My knowledge and
experience on this is also still quite thin so I have very high chance
to fail. I must do this slowly step by step if I want to succeed,
starting by learning how epoch init actually works and how to replicate
sysvinit into epoch init configurations.

Here is my plan at least for this week. I will do the steps on option
2.My target is to replicate the daemon scripts listed below into epoch
init configurations. I will start with a fresh Devuan debootstrap
minimal install on my test PC. So the replication will be based on the
available daemons at that point. And then start adding more daemons one
by one. Let's see how this goes.

As a side note, my main objective is to have init system that are
efficient, small footprint, faster and easier to configure than
sysvinit. I believe that it is not worth to have init systems which can
execute the daemons running in parallel,as the complexity and the racing
conditions only diminish the booting speed that it claims can be
achieved. It looks like epoch fits my objectives.

Cheers,

Anto
----

anto@d945gclf:/etc/init.d$ ls -ln
total 256
-rwxr-xr-x 1 0 0 2227 Apr 15 2013 acpid
-rwxr-xr-x 1 0 0 1071 Nov 23 2009 atd
-rwxr-xr-x 1 0 0 2444 Mar 24 2012 bootlogd
-rwxr-xr-x 1 0 0 1276 Oct 15 2012 bootlogs
-rwxr-xr-x 1 0 0 1281 Jul 14 2013 bootmisc.sh
-rwxr-xr-x 1 0 0 3816 Jul 14 2013 checkfs.sh
-rwxr-xr-x 1 0 0 1099 Jul 14 2013 checkroot-bootclean.sh
-rwxr-xr-x 1 0 0 9673 Jul 14 2013 checkroot.sh
-rwxr-xr-x 1 0 0 1379 Dec 9 2011 console-setup
-rwxr-xr-x 1 0 0 3033 Jul 3 2012 cron
-rwxr-xr-x 1 0 0 2813 Apr 2 01:08 dbus
-rwxr-xr-x 1 0 0 1329 Mar 24 2012 halt
-rwxr-xr-x 1 0 0 10577 Jun 24 2012 hdparm
-rwxr-xr-x 1 0 0 1423 Mar 24 2012 hostname.sh
-rwxr-xr-x 1 0 0 3916 Feb 12 05:35 hwclock.sh
-rwxr-xr-x 1 0 0 7592 Apr 28 2012 kbd
-rwxr-xr-x 1 0 0 1591 Oct 1 2012 keyboard-setup
-rwxr-xr-x 1 0 0 1293 Mar 24 2012 killprocs
-rwxr-xr-x 1 0 0 1990 May 20 2012 kmod
-rwxr-xr-x 1 0 0 995 Oct 15 2012 motd
-rwxr-xr-x 1 0 0 670 Feb 24 2013 mountall-bootclean.sh
-rwxr-xr-x 1 0 0 2128 Feb 24 2013 mountall.sh
-rwxr-xr-x 1 0 0 1508 Jul 14 2013 mountdevsubfs.sh
-rwxr-xr-x 1 0 0 1413 Jul 14 2013 mountkernfs.sh
-rwxr-xr-x 1 0 0 678 Feb 24 2013 mountnfs-bootclean.sh
-rwxr-xr-x 1 0 0 2440 Oct 15 2012 mountnfs.sh
-rwxr-xr-x 1 0 0 1731 Jul 14 2013 mtab.sh
-rwxr-xr-x 1 0 0 4322 Mar 14 2013 networking
-rwxr-xr-x 1 0 0 5658 Aug 13 2014 nfs-common
-rwxr-xr-x 1 0 0 1814 Feb 4 21:03 ntp
-rwxr-xr-x 1 0 0 1346 May 20 2012 procps
-rwxr-xr-x 1 0 0 6120 Oct 15 2012 rc
-rwxr-xr-x 1 0 0 782 Oct 15 2012 rc.local
-rwxr-xr-x 1 0 0 117 Oct 15 2012 rcS
-rw-r--r-- 1 0 0 2427 Oct 15 2012 README
-rwxr-xr-x 1 0 0 639 Mar 24 2012 reboot
-rwxr-xr-x 1 0 0 1074 Mar 24 2012 rmnologin
-rwxr-xr-x 1 0 0 2344 Jun 15 2012 rpcbind
-rwxr-xr-x 1 0 0 3054 Oct 7 2014 rsyslog
-rwxr-xr-x 1 0 0 3200 Oct 15 2012 sendsigs
-rwxr-xr-x 1 0 0 590 Mar 24 2012 single
-rw-r--r-- 1 0 0 4290 Oct 15 2012 skeleton
-rwxr-xr-x 1 0 0 1875 Jun 8 12:30 slim
-rwxr-xr-x 1 0 0 3881 Jun 28 2014 ssh
-rwxr-xr-x 1 0 0 567 Mar 24 2012 stop-bootlogd
-rwxr-xr-x 1 0 0 1143 Mar 24 2012 stop-bootlogd-single
-rwxr-xr-x 1 0 0 731 Mar 11 20:51 sudo
-rwxr-xr-x 1 0 0 6581 May 25 00:07 udev
-rwxr-xr-x 1 0 0 461 May 17 11:31 udev-finish
-rwxr-xr-x 1 0 0 2721 Apr 10 2013 umountfs
-rwxr-xr-x 1 0 0 2195 Apr 10 2013 umountnfs.sh
-rwxr-xr-x 1 0 0 1122 Oct 15 2012 umountroot
-rwxr-xr-x 1 0 0 3111 Oct 15 2012 urandom
-rwxr-xr-x 1 0 0 2666 Mar 2 2012 x11-common
anto@d945gclf:/etc/init.d$