[2018-12-22 17:54] Guillem Jover
> But regardless of the above, I think using alternatives would not be a
> good idea, because then those programs cannot be diverted, something I
> think at least molly-guard is doing.
You mean alternatives could not be diverted? Well, if it is the case,
they I
The problem I see with alternatives is: what happens when I have init X
set as the current alternative and I boot into init Y with a kernel command
line
or with a Grub-init-Y line?
Will I end up with init Y but with all links pointing to init X commands?
Il giorno dom 23 dic 2018 alle ore 15:58
On Sun, Dec 23, 2018 at 02:58:15PM +, Dmitry Bogatov wrote:
> [2018-12-21 11:31] Josh Triplett
> > You might consider submitting a patch to GRUB to add runit to that list,
> > or better yet making that behavior look for symlinks in /lib/inits/ or
> > similar and make an entry for every link
[2018-12-21 23:57] Thorsten Glaser
> On Fri, 21 Dec 2018, Dmitry Bogatov wrote:
>
> > I propose to replace current approach with update-alternatives(1)
> […]
> > Opinions?
>
> No. update-alternatives is too fragile to handle things like
> /bin/sh and init(8).
What do you mean fragile? Mind
[2018-12-21 23:19] Lorenz
> A slightly different approach is also possible:
> Ship only /sbin/init as a alternative link ("the default init" as user
> choice)
> and ship in `init-system-helpers' the following
>
> /sbin/halt
> /sbin/poweroff
> /sbin/reboot
>
[2018-12-21 20:35] Colin Watson
> > (Meanwhile, I don't think it's necessarily a good idea to handle
> > /sbin/init and associated programs with alternatives, not least of which
> > because of the complications of switching the running system's init.)
>
> I quite agree.
Could you please
[2018-12-21 11:31] Josh Triplett
> You might consider submitting a patch to GRUB to add runit to that list,
> or better yet making that behavior look for symlinks in /lib/inits/ or
> similar and make an entry for every link that doesn't match /sbin/init.
> (If you do so with fallbacks to the
On Sat, 2018-12-22 at 20:11:13 +0100, Adam Borowski wrote:
> On Sat, Dec 22, 2018 at 05:54:26PM +0100, Guillem Jover wrote:
> > On Fri, 2018-12-21 at 23:57:38 +0100, Thorsten Glaser wrote:
> > > No. update-alternatives is too fragile to handle things like
> > > /bin/sh and init(8).
> >
> > While
On Sat, Dec 22, 2018 at 05:54:26PM +0100, Guillem Jover wrote:
> On Fri, 2018-12-21 at 23:57:38 +0100, Thorsten Glaser wrote:
> > On Fri, 21 Dec 2018, Dmitry Bogatov wrote:
> >
> > > I propose to replace current approach with update-alternatives(1)
> > […]
> > > Opinions?
>
> > No.
Hi!
On Fri, 2018-12-21 at 23:57:38 +0100, Thorsten Glaser wrote:
> On Fri, 21 Dec 2018, Dmitry Bogatov wrote:
>
> > I propose to replace current approach with update-alternatives(1)
> […]
> > Opinions?
> No. update-alternatives is too fragile to handle things like
> /bin/sh and init(8).
While
On Fri, Dec 21, 2018, 19:19 Lorenz Josh Triplett ha scritto:
> > sysvinit works similarly, with /lib/sysvinit/init
> This was in Jessie, but I don't see any /lib/sysvinit/init in Stretch nor
> in Sid,
> it's /sbin/init now, am I wrong?
>
You are correct. The sysvinit package (which provided the
On Fri, 21 Dec 2018, Dmitry Bogatov wrote:
> I propose to replace current approach with update-alternatives(1)
[…]
> Opinions?
No. update-alternatives is too fragile to handle things like
/bin/sh and init(8).
Also, what Josh Triplett said.
The packages you cited are basically just the hooks to
Josh Triplett ha scritto:
> sysvinit works similarly, with /lib/sysvinit/init
This was in Jessie, but I don't see any /lib/sysvinit/init in Stretch nor
in Sid,
it's /sbin/init now, am I wrong?
Dmitry Bogatov wrote:
>I propose to replace current approach with update-alternatives(1)
>approach. By
On Fri, Dec 21, 2018 at 11:31:24AM -0800, Josh Triplett wrote:
> Dmitry Bogatov wrote:
> > Currently, init system packages (sysvinit-core, runit-init,
> > systemd-sysv) are mutually exclusive -- each of them provides,
> > among other, /sbin/init file and as such, conflicts with rest.
> >
> > This
Dmitry Bogatov wrote:
> [ I am not subscribed. Please keep me in CC. ]
[I'm assuming that CCing the various init system @packages.debian.org
addresses suffices?]
> Currently, init system packages (sysvinit-core, runit-init,
> systemd-sysv) are mutually exclusive -- each of them provides,
> among
[ I am not subscribed. Please keep me in CC. ]
Currently, init system packages (sysvinit-core, runit-init,
systemd-sysv) are mutually exclusive -- each of them provides,
among other, /sbin/init file and as such, conflicts with rest.
This scheme has following drawbacks:
* switching between
16 matches
Mail list logo
