Autor: Fred DC Fecha: A: dng Asunto: Re: [DNG] Devuan-ascii: Upgrading runit to 2.1.2-5 can hose your
system
On 12/08/2016 19:47, Steve Litt wrote:
Hi Steve
[big snip]
Thanks for your valued thought but I consider the incident "water under
the bridge". All what I wanted is to warn PID 1 'runit' users that the
upgrading is a botched affair. As I said, I was able to recover the
system but belive me, its not funny to have the executable of PID 1
wipped of the disk. Obviously 'runsv. got confused. Enough said now.
> ....
> With the ascension of the poetterists within the Debian developer
> community, I have a feeling that, long term, any Devuan packaging of
> Runit (or s6 or Epoch, for that matter) will need to be done by Devuan.
> Therefore, people like you and I should begin the process of defining
> what directories do what in runit, and perhaps define some best
> practices. I'll throw out the first pitch...
> ......
> ......
> The preceding six paragraphs are based on 10 minutes thought: They're
> designed to start things off, and to be modified as needed.
>
I very much like your idea to start defining a common essential
minimal structure. Just of the cuff, we must *not* forget that
installing/installing/removing of deb-packages must be within
the debian-framework and must be compatible with the debian-tools.
Although Debian has gone the systemd route, it seems to me that the
package-management has remained what I call 'sysv-ish'.
BTW, /etc/sv/s6, /etc/sv/runit, and /etc/sv/dtencore is an excelent
suggestion.
To spin it even futher: /etc/runit | s6| etc and
/run/supervise/runit | s6 | etc
or
/var/lib/supervise/runit | s6 | etc (the latest trend by Debian is
/var/lib/supervise)
I don't know much about s6 and dtencore but my guess is that
/etc/service would be OK.
IMHO, that would make a lot of sense. This would be the common
minimal structure of all the supervising init-systems.
The question is, are the authors of the these init-system willing to
cooperate or does Devuan have the manpower-resources to patch them?
Maybe the authors are willing to exchange the hardcoded
path-requirements with exposed variables which can be manipulated to
make it conform to a Devuan-Framework. That would be the easiest way.
Yes certainly. I will come back to you with some more of my thought.