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 B3CF91381F3 for ; Sun, 26 May 2013 10:01:35 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 26EF5E0B54; Sun, 26 May 2013 10:01:33 +0000 (UTC) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 0A73DE0B34 for ; Sun, 26 May 2013 10:01:31 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id hi5so793764wib.2 for ; Sun, 26 May 2013 03:01:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=LnzwR3llpPCFraQsRVpZJd4Ddgn6zNZ4E0IptvENWBM=; b=f5TqzeHK+PwllkcJkCsTgw14fpbsrgxVuvZS13JAOAyKOqTdtu+Y3eTSpuou+qxP7D ge5ZvgRfJpAFiXafMCmgek4BNHdCeSiqoyHNN9scmufyuPXlpZRbZKS9h0gtT8Y5Warf +e5FKBWwWwVUMy0cb9cKtEOPYfBxJD4B2QRhwlsGtjF2Vg3yeyVG+KMl+txIzw096zX7 SziZJeKv+/lG/VoCMB0nRpG3LXpfQlhuYVojcmLmtRschmouuodtLWX4aFix22SKPSrT A8Uh0OF+nV420VfIEt+LrYNQ3cC7aZxbVS6xPU1fLRTA3kaDrdhkKdDly+6KCrkfxmP0 u5mg== X-Received: by 10.180.9.7 with SMTP id v7mr4399134wia.61.1369562490765; Sun, 26 May 2013 03:01:30 -0700 (PDT) Received: from localhost ([80.92.253.14]) by mx.google.com with ESMTPSA id ay7sm9848257wib.9.2013.05.26.03.01.30 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Sun, 26 May 2013 03:01:30 -0700 (PDT) Date: Sun, 26 May 2013 12:01:19 +0200 From: Robert David To: gentoo-dev@lists.gentoo.org Cc: TomWij@gentoo.org Subject: Re: [gentoo-dev] eselect init Message-ID: <20130526120119.2d9d4e3f@gmail.com> In-Reply-To: <20130526112125.6073ef93@TOMWIJ-GENTOO> References: <51A08A68.3020900@gentoo.org> <20130526084332.1a8afa69@gentoo.org> <20130526105823.4d191bc7@gmail.com> <20130526112125.6073ef93@TOMWIJ-GENTOO> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.17; x86_64-pc-linux-gnu) 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-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: ad470361-35e7-40f5-bd26-258efec1f57a X-Archives-Hash: 7c97502f750b319b5a9df56cd251c4ee On Sun, 26 May 2013 11:21:25 +0200 Tom Wijsman wrote: > On Sun, 26 May 2013 10:58:23 +0200 > Robert David wrote: > > > > Increased complexity is never safer. And a wrapper means the > > > additional complexity gets there every boot. And considering how > > > the discussion goes, the wrapper will grow openrc-size in a few > > > months.. > > > > I agree with this. But changing symlinks is not as easy on running > > system (since it can cause inconsistence during rebooot). I think > > that safest way not using wrapper is to stop all services and keep > > only mounted /, than change things (symlinks,configuration update) > > and reboot. > > > > Thus this "eselect init" will let the user confirm and then trigger > > reboot. I do not think that users will change init all the time, > > thus make it better safe and more complex in this change is better > > than check and wrap in all the boots. > > > > Otherwise interesting is preinit handler in OpenWrt: > > http://wiki.openwrt.org/doc/techref/process.boot > > http://wiki.openwrt.org/doc/howto/notuci.config#etcpreinit > > http://wiki.openwrt.org/doc/techref/preinit_mount > > In other words, if you go for the symlink approach you're just moving > complexity to your system instead of into the boot; I don't see why a > wrapper would grow to openrc size, that's just a bold exaggeration. Newer say that wrapper will grow openrc size, and also dont know why it would be bad. The point is somewhere else. I really dont know how many user will switch inits and how many of them will do this regularly. But the wrapper will be executed every boot. So even a tiny mistake can produce booting problems even for those who did not wanted to change anything in init process. On the other hand mistake in some system process will affect only those who would actually switching. It is only calculation of possible risks. I also did not say it must be done the reboot way I mentioned, this is only and different point what can be though about. > > I'd rather have a clean wrapper that just works than an unclean way to > cover the reboot madness that comes along; forcing a reboot, really? > I do not see point not forcing reboot when I'm switching init, or let say suggesting. When you update your kernel config, rebuild and install you also can stay working, but you have to be prepared to have nonworking modules that was not inserted before.