On Mon, 2008-03-03 at 15:53 +0100, Fabian Groffen wrote: > On 03-03-2008 13:36:25 +0000, Roy Marples wrote: > > On Thursday 28 February 2008 11:22:13 Roy Marples wrote: > > > So the only thing left (aside from bug fixing) is to instruct OpenRC > > > dependency > > > code that it's in a prefix and to respect the noprefix keyword in > > > services, > > > or > > > to provide dummy services. > > > > This is now done. > > > > I have OpenRC fully working in a prefixed non priviledged install on a > > NetBSD > > box. > > Can you define how this is working? Do you just have NetBSD and install > OpenRC in /my/arbitrary/path, or do you have a full set of utilities > under /my/arbitrary/path with OpenRC as one of them? > > > The only question I have left is what mechanism resets service state, as > > the > > prefixed state dir needs will presist between reboots which isn't desirable. > > startprefix could maybe start some sort of process that lives on, > activated like keychain does, such that multiple startprefix invocations > do not start the system all the time -- if that is desired at all. In > a real scenario it may be just a hook from the host OS's start/stop > mechanism to tell OpenRC in what state it should run.
Must admit not having looked at OpenRC yet - maybe I understood sth. wrong, but: +1 for registering OpenRC into host OS's specific init.d mechanism. Here I'm doing so with distccd on ia64-hpux, having some (host OS specific) script in (not yet gentoo-) prefix, understanding additional '--install [name]' - or have a separate command for that. This needs to be run as root once to register into host OS's init.d mechanism. For hpux fex this just is adding some symlinks: /sbin/init.d/name -> /my/prefix/sbin/init.d/distccd /sbin/rc3.d/S990name -> /sbin/init.d/name # to start in runlevel 3 /sbin/rc2.d/K100name -> /sbin/init.d/name # to kill for runlevel 2 When doing so with OpenRC's main process, it could integrate smoothly with normal system reboot and start prefixed init.d scripts. /haubi/ -- Michael Haubenwallner Gentoo on a different level -- [email protected] mailing list
