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 345401381F3 for ; Mon, 19 Aug 2013 06:19:27 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E40C0E0C9B; Mon, 19 Aug 2013 06:19:25 +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 56240E0C9A for ; Mon, 19 Aug 2013 06:19:25 +0000 (UTC) Received: by smtp.gentoo.org (Postfix, from userid 617) id 9304D33EBE7; Mon, 19 Aug 2013 06:19:24 +0000 (UTC) Date: Mon, 19 Aug 2013 06:19:24 +0000 From: Sven Vermeulen To: gentoo-project@lists.gentoo.org Subject: Re: [gentoo-project] rfc: separate /usr preparation vote Message-ID: <20130819061924.GA15036@gentoo.org> Mail-Followup-To: gentoo-project@lists.gentoo.org References: <20130817222025.GA15851@linux1> <21008.27285.932342.231536@a1i15.kph.uni-mainz.de> <20130819024809.GA9962@linux1> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20130819024809.GA9962@linux1> User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: 09f1aa70-afd6-4703-b180-fef5c4d6f8ae X-Archives-Hash: a8de3633ac6e0d8d2a9b2ec3a1c1ea34 On Sun, Aug 18, 2013 at 09:48:09PM -0500, William Hubbs wrote: > > I just don't see any reason for waiting, at least not right now. If > > the argument is that we should give users some period of time to > > prepare, then we should be sending out some kind of specific news item > > telling them what preparations to make and THEN waiting. > > The vote is to make sure all of the necessary documentation is in place, > so this isn't really part of it. But, yes, once this vote passes, > communication to users as the changes happen will be important. Documentation can always be improved, but I do feel it is up to the task already. We document how to create an initramfs using genkernel (which is dead easy) and mention several times that a separate /usr (or root on LVM) requires an initramfs. All our examples use the initramfs as well. > > Finally, I could see the /usr merge as a POSSIBLE reason to move > > things sooner. If somebody wants to propose some plan to make that > > happen they should do so, and we can debate it on this list and so on. > > However, I don't see any value in moving a bunch of stuff around > > purely for the sake of a /usr merge when there isn't any plan to > > finish the work. If anybody is thinking about that being the driver > > they need to have a plan that actually gets us to the end goal, and of > > course we need to agree that this is even a goal we want to have. > > The /usr merge is a totally separate issue that I really don't want to > bring into this discussion. There are people who are fine with us > cleaning up the separate /usr issue, but opposed to the /usr merge, so > that needs to be a separate item imo. Yes please; merging / <-> /usr has impact beyond just documentation and initramfs. For SELinux for instance, that means our policies will need to be adjusted so all /bin/* contexts also get assigned to /usr/bin (and /sbin to /usr/sbin) and symlinks are "accepted" where they are currently not. I think for such a merger, we'll need to know what will be the goal, and set steps in that direction that make it so a transition is not full-park, big-bang, but rather gradually with little to no end user involvement (step-wise). Wkr, Sven Vermeulen