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 1RiBpB-0007zJ-4t for garchives@archives.gentoo.org; Tue, 03 Jan 2012 21:23:16 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BC73A21C029; Tue, 3 Jan 2012 21:23:04 +0000 (UTC) Received: from amun.cheops.ods.org (amun.cheops.ods.org [83.161.135.166]) by pigeon.gentoo.org (Postfix) with ESMTP id 71A9A21C269 for ; Tue, 3 Jan 2012 21:22:19 +0000 (UTC) Received: from nut.cheops.ods.org ([172.17.2.83] helo=gentoo.org) by amun.cheops.ods.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RiBoG-0008G3-7R for gentoo-dev@lists.gentoo.org; Tue, 03 Jan 2012 22:22:18 +0100 Date: Tue, 3 Jan 2012 22:22:15 +0100 From: Fabian Groffen To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] rfc: locations of binaries and separate /usr Message-ID: <20120103212215.GU780@gentoo.org> Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <1325401942.12935.11.camel@TesterTop4> <4F000C32.6020602@gentoo.org> <1325449284.12935.21.camel@TesterTop4> <20120101202355.30098545@googlemail.com> <1325454648.12935.24.camel@TesterTop4> <4F016DBE.2000209@gentoo.org> <1325616625.7238.23.camel@TesterBox.tester.ca> <20120103190255.GA13817@linux1> <20120103191206.GP780@gentoo.org> <20120103200120.GB13936@linux1> 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: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0YcXTHV6G4K6ZTkr" Content-Disposition: inline In-Reply-To: <20120103200120.GB13936@linux1> User-Agent: Mutt/1.5.21 (Darwin 11.2.0, VIM - Vi IMproved 7.3) Organization: Gentoo Foundation, Inc. X-Content-Scanned: by amun.cheops.ods.org (Exim Exiscan) using SpamAssassin and ClamAV X-Archives-Salt: e37c5839-1a7f-4166-937a-f0c76cf82f79 X-Archives-Hash: a7e6d87ede79e0103674674f6f734037 --0YcXTHV6G4K6ZTkr Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 03-01-2012 14:01:20 -0600, William Hubbs wrote: > On Tue, Jan 03, 2012 at 08:12:06PM +0100, Fabian Groffen wrote: > > > I think the best way to do this part of it is going to be to just fol= low > > > the upstream packages. When they release a new version that installs = in > > > /usr, just allow that to happen. Eventually there will be very little= in > > > /{bin,sbin,lib}, maybe nothing besides a couple of symbolic links li= ke > > > /bin/sh. > >=20 > > What packages would that be? If you're thinking about coreutils, just > > trim down the ebuild by not moving some of the tools to /bin. Our > > ebuild makes it conform to FHS, not the coreutils buildsystem itself. >=20 > Yes, coreutils will have to be reworked in that case. I don't know what > the upstream build system does, but we will have to take a look at it. Upstream build system has all binaries just installed in $(PREFIX)/bin, like normal autoconf-based projects. > I'll have to go through on my system at > least and find all of the ebuilds that install things in > /{bin,sbin,lib}. I'll open a tracker bug as soon as udev-176 is > released; this will list all of the things we need to do to complete the > migration. I would suggest not to do this. It's more interesting to know what udev really requires to be in /usr/bin. > Basically I have these in my head: >=20 > * mask udev-176 in the tree. > * figure out and document how to make a simple initramfs with dracut. > * unmask udev 176 making sure to point users with a separate /usr > partition to how to make an initramfs (I could probably do this with > ewarns in the ebuild and maybe a news item before we go stable). > * stabilize a version of dracut. > * stabilize >=3Dudev-176 and kmod. > * Now start stabilizing packages with things installed in /usr instead > of /. If the system can work with things being in /, why would we have to move away from that? I don't like my systems breaking, and this is a likely candidate to do so. E.g. also gcc-config needs changing for this. And baselayout/openrc. How many locations for functions.sh are there already in scripts now? > If you do not have separate /usr, you could just enjoy the ride. All > of this would be transparent to you. If you do have separate /usr, the > critical step will be bringing up an initramfs once you upgrade to > udev-176. Once that is done, you could also just enjoy the ride. >=20 > Thoughts? Let's just first see how the rest of the world reacts to all of this. We've waited serveral years with baselayout-1 -> openrc/baselayout-2, so I wouldn't mind doing some waiting here too. It doesn't look like there's much going to change. I can't imagine bash devs dropping /bin =66rom bare default PATH (we control the default PATH), neither that glibc folks drop /lib from the search path (although more likely since it's more limited to Linux). Perhaps, even start to experiment with this in an overlay (it's relatively easy to start, just disable gen_usr_ldscript, fix bash to pass --prefix=3D/usr and coreutils not to move bins) and try to see how hard migration is with zlib moving around (shouldn't be too hard with ELF, is a downright drama with Mach-O && without portage's preserve-libs). But also, starting to experiment to see how easy it is to let things as they are. udev might consider a world without /bin and /lib, but maybe what's in there isn't much interesting to it anyway. Most stuff is installed in /usr for a reason. --=20 Fabian Groffen Gentoo on a different level --0YcXTHV6G4K6ZTkr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (Darwin) iEYEARECAAYFAk8DcYcACgkQX3X2B8XHToms8wCdEgp47MwRoC7yQxtvWP+jCW7t HeIAmwb8JboIvgdjyJCoKBcheIVKHcg/ =exBE -----END PGP SIGNATURE----- --0YcXTHV6G4K6ZTkr--