Re: [gentoo-dev] rfc: locations of binaries and separate /usr

[William Hubbs <williamh@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 3218 bytes --]

On Sun, Jan 01, 2012 at 06:54:34PM +0100, Michał Górny 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.
> 
> 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.
> 
> 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.

> 
> 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.
> 
> 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


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]