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 1RhRwN-0007H8-47 for garchives@archives.gentoo.org; Sun, 01 Jan 2012 20:23:35 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C3E3A21C06E; Sun, 1 Jan 2012 20:22:46 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 2678B21C19C for ; Sun, 1 Jan 2012 20:21:28 +0000 (UTC) Received: from [192.168.1.102] (modemcable002.97-23-96.mc.videotron.ca [96.23.97.2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: tester) by smtp.gentoo.org (Postfix) with ESMTPSA id 35A641B4007 for ; Sun, 1 Jan 2012 20:21:27 +0000 (UTC) Message-ID: <1325449284.12935.21.camel@TesterTop4> Subject: Re: [gentoo-dev] rfc: locations of binaries and separate /usr From: Olivier =?ISO-8859-1?Q?Cr=EAte?= To: gentoo-dev@lists.gentoo.org Date: Sun, 01 Jan 2012 15:21:24 -0500 In-Reply-To: <4F000C32.6020602@gentoo.org> References: <20120101015947.GA9914@linux1> <1325401942.12935.11.camel@TesterTop4> <4F000C32.6020602@gentoo.org> Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-HfDPSzhvb2XwFdmO4P/B" X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 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 X-Archives-Salt: ae5c91e9-2a4a-44e8-9441-53021ae42e5e X-Archives-Hash: 2c6ed8d4ac0bd88ff8c03b5e16e0be65 --=-HfDPSzhvb2XwFdmO4P/B Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, 2012-01-01 at 15:33 +0800, Patrick Lauer wrote: > On 01/01/12 15:12, Olivier Cr=C3=AAte wrote: > > Hi, > > > > On Sat, 2011-12-31 at 19:59 -0600, William Hubbs wrote: > >> I have been working with robbat2 on solutions to the separate /usr iss= ue > >> (That is why I have specifically cc'd him on this email) > >> which will allow people to not use an initramfs. If we migrate > >> everything off of the root fs to /usr, all of those solutions become > >> moot. On the other hand, if we don't migrate, we run the risk of > >> eventually having our default configuration not supported by upstream. > > I think the general consensus among other distros is that initramfs is > > the new /. Many core elements of the Linux system will start installing > > themselves in /usr, starting with udev, so we won't have a choice > > anyway. Also, I doubt it's currently possible to boot a Gentoo system > > without /usr mounted anyway. > "initramfs is the new /" ... and no one asked if maybe that doesn't > really make sense? >=20 > That people are now actively working on forcing one big system partition > is annoying, but I really don't see the need to add a layer or two of > complexification just because, well, why not. We're absolutely not forcing a single system partition. We're just saying that the bits required to mount all the partitions you want should be in an initramfs. > >> 1) Start migrating packages along with upstream and have everyone who > >> has a separate /usr (including me by the way) start using an initramfs > >> of some kind, either dracut or one that we generate specifically for > >> gentoo. The reason I suggest the initramfs, is, unfortunately if we > >> migrate everything, nothing else would work. > > I also don't see a good reason to not adopt dracut, > Make it work and I'll reconsider it, until then genkernel wins by default= . > > re-implementing > > something that already works and is maintained by a competent upstream > > seems wasteful to me. I really don't see why people resist using an > > initramfs so much. > What does it add, apart from time to the boot process? For some setups > (like my notebook with luks+lvm) there's no reasonable way around it, > but on my desktop it's worse than useless. I don't see how it adds time to the boot process. Either you have a single big partition (and then you don't even need an initramfs), or you have multiple partitions and then most of the time is mounting them anyway. > > The udev/kmod/systemd/dracut effort to standardise the base userspace o= f > > Linux is probably scary for quite a few Gentoo-ers as it means that the > > end result of an installed Gentoo system will be less differentiated > > than it was before. But it still is a step in the right direction as > > most of these standardized pieces are much better than what we currentl= y > > have. The OpenRC/baselayout-2 fiasco, not much better than baselayout-1 > > and unmaintained upstream shows that even a relatively large > > distribution like us can't maintain a competitive base system solution, > Eh what? > > I don't see an advantage in replacing a known-good solution with some > random stuff that mostly doesn't work yet just because it's the future. Random stuff that was well though to work together and works well enough that all other major distros are adopting it. > > adopting the udev/kmod/systemd way will allow us to use all the work > > that they are doing and instead concentrate on making a better system. > > > "Better" means no lennartware to me. I want to be able to fully debug > init script failures, which systemd makes very hard to impossible. On > some machines I have changes in the startup that would mean having to > hack up something in C and hope that it doesn't crash init for systemd > (what the bleeeep?) You can start services with a shell scripts in systemd, you just have to aim the .service unit file to you shellscript..=20 > Please don't try to bring the GnomeOS vision of having MacOS without > paying for it to my computing experience ... Honestly, so many things just work on MacOS and just need hours of tweaking for us.. --=20 Olivier Cr=C3=AAte tester@gentoo.org Gentoo Developer --=-HfDPSzhvb2XwFdmO4P/B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAk8AwEQACgkQHTiOWk7ZorvZ9gCfU1/H/Fi5eVnwf+gmE5C2/o8o mQYAn06YMvNjkdo5BiTz/H3Ta6n6jpBm =lA2L -----END PGP SIGNATURE----- --=-HfDPSzhvb2XwFdmO4P/B--