From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1RiR7c-0000Xb-6G for garchives@archives.gentoo.org; Wed, 04 Jan 2012 13:43:16 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AA48021C026; Wed, 4 Jan 2012 13:42:56 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id A13D521C168 for ; Wed, 4 Jan 2012 13:42:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 2ADBE1B4012 for ; Wed, 4 Jan 2012 13:42:06 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -3.169 X-Spam-Level: X-Spam-Status: No, score=-3.169 tagged_above=-999 required=5.5 tests=[AWL=-0.393, BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_NUMERIC_HELO=1.164, RP_MATCHES_RCVD=-1.828, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TVD_APPROVED=2.09] autolearn=no Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZtffs8nsIfS for ; Wed, 4 Jan 2012 13:41:59 +0000 (UTC) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by smtp.gentoo.org (Postfix) with ESMTP id D2DAF1B401A for ; Wed, 4 Jan 2012 13:41:58 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RiR6C-0007o9-Jy for gentoo-dev@gentoo.org; Wed, 04 Jan 2012 14:41:48 +0100 Received: from 109.176.253.253 ([109.176.253.253]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Jan 2012 14:41:48 +0100 Received: from slong by 109.176.253.253 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Jan 2012 14:41:48 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Steven J Long Subject: [gentoo-dev] Re: rfc: locations of binaries and separate /usr Followup-To: gmane.linux.gentoo.devel Date: Wed, 04 Jan 2012 13:50:45 +0000 Organization: Friendly-Coders Message-ID: References: <20120101015947.GA9914@linux1> <20120101085326.GA1928@gentoo.org> <20120102194341.3766edeb@pomiocik.lan> 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="UTF-8" X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 109.176.253.253 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 75c65d01-93bd-4c71-9a2b-f1888d116f81 X-Archives-Hash: bc9d44142c64e1484098d5e36908afa9 Micha=C5=82 G=C3=B3rny wrote: > On Sun, 1 Jan 2012 08:53:26 +0000 > Sven Vermeulen wrote: >=20 >> On Sat, Dec 31, 2011 at 07:59:47PM -0600, William Hubbs wrote: >> > The goal is to deprecate /bin, /lib, /sbin and /usr/sbin. My >> > understanding is that they want to move software that is installed >> > in /bin, /sbin and /usr/sbin to /usr/bin. Also, they want to move >> > everything from /lib to /usr/lib. >>=20 >> I don't like this one bit. Things used to be simple with the "split" >> between /bin and /usr/bin (and its related directories), this isn't >> going to make it more simple. >=20 > Simple? Should I start requesting additional packages moved into rootfs > because I feel like needing them? Things can and will go more ugly, > and I wouldn't be surprised if anytime soon people will start > complaining because they ran out of space on their rootfs. >=20 Well, it is conceptually quite simple: if it's needed in single-user mode= to=20 get your system up and running again, it belongs in rootfs, and if it isn= 't,=20 then leave it in user-land. The thing I don't understand is why it is necessary to move stuff from /b= in=20 to /usr/bin. After all, if you're running the "approved" setup you don't=20 have a separate /usr so all the binaries are available from the get-go. What does moving them enable that can't be done now? Sure, if you have binaries in /bin that link to libraries in /usr/lib tha= t=20 could be an issue, but only if you're running with a separate /usr and do= n't=20 have it mounted when udev starts. So again, not the "approved" setup, and= =20 something you as an admin already have to deal with by making sure /usr i= s=20 mounted when udev starts (either via an initramfs, or by a tweak to udev=20 startup scripts[1].) wrt GNU coreutils installing to /usr by default, that's so of every GNU=20 package, since they default to a prefix of /usr/local and it's up to a=20 distro (or the end-user) to configure them differently; in general the=20 package assumes it's an addition to the system, unless told otherwise. (Additionally I'd say that binaries installed to /bin that require librar= ies=20 installed to /usr is a bug, but something that should be dealt with=20 separately. Though with the direction people seem to think is needed, I'm= =20 not sure how much effort anyone will put into that.) [1] http://forums.gentoo.org/viewtopic-p-6866484.html --=20 #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)