From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1JWCwI-0000wT-8P for garchives@archives.gentoo.org; Mon, 03 Mar 2008 15:50:54 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AE8C8E04FD; Mon, 3 Mar 2008 15:50:52 +0000 (UTC) Received: from email.aon.at (WARSL404PIP1.highway.telekom.at [195.3.96.112]) by pigeon.gentoo.org (Postfix) with ESMTP id 423B3E04FD for ; Mon, 3 Mar 2008 15:50:52 +0000 (UTC) Received: (qmail 15686 invoked from network); 3 Mar 2008 15:50:50 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.0 (2007-05-01) on WARSBL603.highway.telekom.at Received: from m4508p001.adsl.highway.telekom.at (HELO [10.0.0.1]) ([212.183.79.97]) (envelope-sender ) by smarthub96.highway.telekom.at (qmail-ldap-1.03) with SMTP for ; 3 Mar 2008 15:50:50 -0000 Subject: Re: [gentoo-dev] Google SOC 2008 From: Michael Haubenwallner To: gentoo-dev@lists.gentoo.org In-Reply-To: <20080303145320.GD7729@gentoo.org> References: <20080227142158.GB315@gentoo.org> <6543edc8f8bb6bc50f3f08e90400353f@marples.name> <200803031336.25672.roy@marples.name> <20080303145320.GD7729@gentoo.org> Content-Type: text/plain Date: Mon, 03 Mar 2008 16:50:49 +0100 Message-Id: <1204559449.6937.21.camel@salomon-22> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 X-Mailer: Evolution 2.10.2 Content-Transfer-Encoding: 7bit X-Archives-Salt: ab2676ae-3765-40f6-b4d1-6b80e205c368 X-Archives-Hash: b6bd01c3d573a4fcc52e22480cd26bb1 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 -- gentoo-dev@lists.gentoo.org mailing list