On Sun, 28 Oct 2018 11:10:46 +0100
aitor_czr <aitor_czr@???> wrote:

> Hi,
>
> On 10/28/2018 10:55 AM, Olaf Meeuwissen wrote:
> > Hi Didier,
> >
> > Didier Kryn writes:
> >

> >> Le 28/10/2018 à 06:24, Olaf Meeuwissen a écrit:  
> >>>     sed -i 's/ascii/ceres/' /etc/apt/source.list
> >>>     apt update
> >>>     apt upgrade  
> >>    Hi Olaf.

> >>

> >>    Do you for sure mean 'apt upgrade' ? Because I would have
> >> thought of 'apt dist-upgrade'.  
> > Whichever of the two does what you want it to:-P

> >
> > I was thinking of doing the above after a minimal install, i.e. a
> > netinst without any desktop stuff. IIUC, Steve is looking for a
> > setup to work on runit scripts so that would really be all that
> > he'd need.
>
> I want to build an image based on ceres and focused to the
> development of runit. After beginning on the packaging stuff, i have
> a question for you, especially for Steve: do you want to break its
> dependency on the initscripts for testing purposes?

As far as I know, runit has no dependency on the initscripts housed
in /etc/rc.d and below. I don't think a runit package should depend on
those, or sysvinit. HOWEVER, in reality, if one uses runit only as a
supervisor, it needs a PID1, and sysvinit is probably the best PID1 to
match with runit.


> Or only on a
> concrete package like sysvinit-utils (a part of it containing only
> killall5, fstab-decode and the init-d-script) or some other one?

Killall5 is a must for any init system's shutdown. I'm not sure why
it's part of sysvinit in any way.

>
> I've just built the grub configured with runit as the default init
> system

What happens when you boot?

>
> It's night now in the united states... I look forward to your
> answers :)

As you can tell by my answers (non-answers, really), I'm very unfamiliar
with the entire subject of packaging. I have not been able to answer
your very concise and specific questions.

Instead of answering your specific questions, let me give you some
general principles:

* Installing any one init and/or supervisor should not in any way
sabotage or require the uninstallation of any other init and/or
supervisor. You never want installations of runit, s6,
daemontools, perp, nosh, or sysvinit interfering with each other. This
requirement has quite a few ramifications if you think of it.

* As far as I can tell, runit has very few dependencies. It requires a
POSIX environment, a normal /bin/sh, and yes, I wouldn't use it
without the ability to use killall5. Other than those, runit stands
alone.

* Runit could be split up into runit supervisor and runit PID1. In that
case, the PID1 package would include rc scripts 1, 2 and 3,
and /usr/bin/runit-init, which is runit's PID1 executable.

* Executable names for the PID1 executable of each init system should be
distinct, so they don't clobber each other. None should be named the
obvious "init", except perhaps for the PID1 of sysvinit, which might
be grandfathered in (I don't know). If it's grandfathered in, there
should be a hard-linked name sysvinit-pid1 or something like that so
that one could replace the current /bin/init with a symlink to
runit-init or s6-linux-init or suckless-init or whatever.


SteveT

Steve Litt
September 2018 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz