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 <gentoo-dev+bounces-49149-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1RhmDv-0001Cw-CM
for garchives@archives.gentoo.org; Mon, 02 Jan 2012 18:03:03 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 389B221C329;
Mon, 2 Jan 2012 18:02:45 +0000 (UTC)
Received: from mail-gy0-f181.google.com (mail-gy0-f181.google.com [209.85.160.181])
by pigeon.gentoo.org (Postfix) with ESMTP id 72A4B21C363
for <gentoo-dev@lists.gentoo.org>; Mon, 2 Jan 2012 18:00:26 +0000 (UTC)
Received: by ghrr19 with SMTP id r19so6196990ghr.40
for <gentoo-dev@lists.gentoo.org>; Mon, 02 Jan 2012 10:00:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=sender:date:from:to:cc:subject:message-id:mail-followup-to
:references:mime-version:content-type:content-disposition
:in-reply-to:user-agent;
bh=j8GIpndG+78bdjl9qoHDzdXu56eG3WZSsOszxkd36pc=;
b=xrgtMjfdQFvPEgQpD9NHZDdGHDBR//ExqSV5VWzbrhdOrrDefzKelDTlWE0UbqsRBR
JkQasHEcDZIqpBkVt7AhYFgNXgJQKpGrEf3BW+ZE+PgLXILjKWrSHAhuIZxcbI7Eo4qG
ezdNVv9RF/0NGTORFbTOrqSHXyscQWgCK4m3w=
Received: by 10.236.155.40 with SMTP id i28mr64115329yhk.130.1325527225908;
Mon, 02 Jan 2012 10:00:25 -0800 (PST)
Received: from linux1 (cpe-76-187-77-158.tx.res.rr.com. [76.187.77.158])
by mx.google.com with ESMTPS id o9sm69997389yhk.20.2012.01.02.10.00.23
(version=SSLv3 cipher=OTHER);
Mon, 02 Jan 2012 10:00:25 -0800 (PST)
Sender: William Hubbs <w.d.hubbs@gmail.com>
Received: by linux1 (sSMTP sendmail emulation); Mon, 02 Jan 2012 11:54:57 -0600
Date: Mon, 2 Jan 2012 11:54:57 -0600
From: William Hubbs <williamh@gentoo.org>
To: =?utf-8?B?TWljaGHFgiBHw7Nybnk=?= <mgorny@gentoo.org>
Cc: gentoo-dev@lists.gentoo.org, robbat2@gentoo.org
Subject: Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Message-ID: <20120102175457.GB1636@linux1>
Mail-Followup-To: =?utf-8?B?TWljaGHFgiBHw7Nybnk=?= <mgorny@gentoo.org>,
gentoo-dev@lists.gentoo.org, robbat2@gentoo.org
References: <20120101015947.GA9914@linux1>
<20120101185434.3d019941@pomiocik.lan>
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
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="9zSXsLTf0vkW971A"
Content-Disposition: inline
In-Reply-To: <20120101185434.3d019941@pomiocik.lan>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Archives-Salt: d410e024-2545-4447-8a07-6e2969f18ed3
X-Archives-Hash: a4fd251c6f722e90e1c627114fd37037
--9zSXsLTf0vkW971A
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Jan 01, 2012 at 06:54:34PM +0100, Micha=C5=82 G=C3=B3rny wrote:
> On Sat, 31 Dec 2011 19:59:47 -0600
> We should *at least* start doing some preparations, like ensuring that
> random things don't unnecessarily hardcode /sbin or /bin paths. Most
> importantly, if a particular tool runs in a complete environment (which
> is true for most of the cases), there is no need to hardcode paths to
> tools.
>=20
> As I see it, 2) seems achievable within a reasonable time now. It
> shouldn't require any specific changes from users (except for fixing
> their own broken scripts) yet some tree-wide action of fixing hardcoded
> paths.
>=20
> We could create /sbin and /usr/sbin symlinks as well but that shouldn't
> be really necessary, especially if we prepare packages well beforehand.
> Introducing such symlinks would be hard to perform and getting rid of
> them later would be even harder; mostly due to PMS-enforced limitations.
I'm not really a fan of the compatibility symlinks either the more I
think about it. I think that basically packages can revbump to make this
migration happen, or in the case of udev and kmod and other upstreams
that support it, not hard code the configuration.
>=20
> For a long-term view, 1) is the only way to go. Splitting packages
> randomly between rootfs and /usr was never really correct, and we
> especially shouldn't force users to junk their systems with shattered
> packages and cheap glue to keep it all working.
>=20
> I'd suggest going the other way than I did with kmod. Temporary IUSE
> like 'install-to-usr', disabled by default for now. Packages having
> that IUSE should have correct USE-dependencies, and users who need not
> to use that could just enable 'install-to-usr' globally (we'd probably
> want to mask it first).
I'm not sure that a use flag is a good idea for this, because there will
definitely be people who would turn it off, and with upstreams assuming
that this is how things are installed, those who turn it off will have
broken systems.
Here is My thought about how we can make this transition happen:
* Right now, I can re-work our kmod ebuild to install to its default
locations in /usr.
* When udev 176 is released, I'll put it in the tree, masked, installing
to its default locations. I can actually rework the live ebuild right
now to do this.
* I will then open a tracker for issues that will need to be fixed
before we can unmask it.
* Next, we will need people to unmask udev-176 and test to find issues.
I will definitely be one of these since I have separate
/usr on my desktop, however, I can't test all possible
configurations/packages here, so the more the merrier.
* We also need to get a better understanding of dracut at this point. I
believe that making an initramfs is as simple as running:
dracut "" -H
as root. Then you have to add it to your boot loader. The one thing I
haven't figured out yet is whether it is possible to create an
initramfs that doesn't have to be updated with every kernel upgrade.
* Once the issues are ironed out we unmask udev-176 and go from there.
What does everyone think? What am I leaving out?
William
--9zSXsLTf0vkW971A
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
iEYEARECAAYFAk8B73EACgkQblQW9DDEZTh+bgCaAp38JgUfHrL7CD7QFotaF3sO
B6kAn2Maed55ml8yFfZI6U5DNR1JDr0S
=5llR
-----END PGP SIGNATURE-----
--9zSXsLTf0vkW971A--