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

[Duncan]

William Hubbs posted on Sat, 31 Dec 2011 19:59:47 -0600 as excerpted:

> a significant change is taking place with several upstreams that will
> affect us in gentoo[.  Boot-critical components such as Udev, kmod,
> etc], are advocating a major change to the locations where binaries
> and libraries are stored on linux systems.
>
> 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.

> 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 see three options:
>
> 1) Start migrating packages along with upstream[. Have separate /usr
> users] start using an initramfs [as previously discussed onlist].
>
> 2) Combine the sbin and bin directories both  on the root filesystem and
> in /usr by moving things from /sbin to /bin and /usr/sbin to /usr/bin.
>
> 3) Try to maintain  things the way they are as long as possible.
>
> Whether or not I like what is happening personally, I think we should
> consider the first option, because I think it will get more and more
> difficult for us to do anything else over time. And we will eventually
> find ourselves not supported by upstreams.

I'm for #1 (migrate along with upstream) as well.

Gentoo has historically been both "light patch", with a policy of staying 
close to upstream if possible, and "customizer's choice", allowing users 
far more flexibility than most distros.  Keeping both goals in mind, 
migrating with upstream is ultimately the only viable alternative for a 
whole host of reasons including both staying close to upstream and simple 
manpower resource issues.

That said, we can continue to try to support a separate /usr as long as 
possible, while switching new installs to the new way and changing the 
handbook to document it, preferably as soon as possible.  Further, as 
previously discussed, a near-static bare-minimal initramfs that can be 
configured and forgotten about for long periods over many kernel upgrades 
should make the switch as painless as possible at least for "simple" bare-
partition installations.


As for the switchover, I had already been thinking about it here and thus 
have a couple ideas I'd very much like to see implemented in portage/PM/
base.eclass that could definitely help, along with a USE flag. I'll call 
them "migrated-rootfs" and "migrateroot-strict" for purposes of 
discussion, here, and assume they're both portage features and that 
migrated-rootfs is also a USE flag

FEATURES=migrated-rootfs would set a USE-default for migrated-root-to-usr 
so that it'd default to ON, and would indicate that a user is an "early 
adopter" of the new layout, preferring migration as soon as possible.  
Users could still set the USE flag as desired for specific packages, at 
least at first, tho at some point it'd probably first be made a profile 
default, and ultimately profile-masked either on or off.

Additionally, FEATURES=migrated-root would expand the collision-protect 
feature to check for and warn on both same-package and cross-package 
collisions between related dirs, with all four bin/sbin root/usr dirs 
checked for name collisions, and both lib dirs (for single lib, 
additional pairs for multilib) checked as well.

Optionally, if implementation is easy enough, have portage simply remove 
symlinks to identically named files that would otherwise set off the 
warning.  This is a major reason for having it a feature and a USE flag 
both, since if this is implemented, portage would take preventive action 
quite apart from whether an ebuild had been updated to use the USE flag 
or not.

FEATURES=migrateroot-strict would make those collision warnings fatal, 
much like FEATURES=multilib-strict does for its multilib checks.  (As an 
amd64 user who had this feature on for years, until I switched to no-
multilib, that's what the idea is based on.)


The goal would be to allow early adopter users to set the less strict 
version and run a --empty-tree @world update, then grep the logs for the 
warnings it turned on.  If none occurred and /usr is either already on 
the same filesystem or they have the appropriate early-boot measures in 
place, they could feel reasonably confident about setting up symlinks 
pointing to the /usr/bin and /usr/lib dirs as appropriate, and could then 
set FEATURES=migratedroot-strict to ensure it stays "clean", since after 
that any attempted merge that would collide would be fatal.

Alternatively users could just set the strict version and see what 
breaks, instead of grepping the logs for the warnings.

Since this would leverage the code already in place and tested for 
collision-protect and multilib-strict, cross-package checking should be 
fairly easy to implement, but same-package checking and/or actively 
stripping colliding symlinks may involve rather more new code.

Zac?  Other portage,/PM/PMS folks?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman