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
