From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 1DF0C1381F3 for ; Fri, 21 Jun 2013 15:49:09 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A4607E08BD; Fri, 21 Jun 2013 15:49:05 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 8CF7DE085B for ; Fri, 21 Jun 2013 15:49:04 +0000 (UTC) Received: from [192.168.1.204] (39.164.16.95.dynamic.jazztel.es [95.16.164.39]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pacho) by smtp.gentoo.org (Postfix) with ESMTPSA id F380A33E3CC for ; Fri, 21 Jun 2013 15:49:02 +0000 (UTC) Message-ID: <1371829739.2486.20.camel@localhost> Subject: Re: [gentoo-dev] eselect init From: Pacho Ramos To: gentoo-dev@lists.gentoo.org Date: Fri, 21 Jun 2013 17:48:59 +0200 In-Reply-To: <20130621143657.GA26044@linux1> References: <51A08A68.3020900@gentoo.org> <20130620205609.GB23719@linux1> <20130621043959.7eae0921@gentoo.org> <51C42B33.9090709@gentoo.org> <1371814006.2486.10.camel@localhost> <51C43DEA.6000006@gentoo.org> <20130621143657.GA26044@linux1> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.3 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 Content-Transfer-Encoding: 8bit X-Archives-Salt: 2997c22b-1925-4d3a-943c-168d848eef6e X-Archives-Hash: bc7bd30b4c824882e2cea481a1fb0d37 El vie, 21-06-2013 a las 09:36 -0500, William Hubbs escribió: [...] > No, he has his own versions of the systemd and sysvinit ebuilds which > move some of the installation to non-standard places as part of this > machinery, so it is not opt-in. > > Also, there was an email on this thread showing that using > init=/sbin/einit works, so I'm not seeing what mgorny's objections are. > > William I think mgorny was referring to a case where einit fails to work and, then, kernel will fallback to using /sbin/init, that could cause problems as it would always run /sbin/init from sysvinit... but maybe he was referring to something else :|