1 |
William Hubbs posted on Sat, 31 Dec 2011 19:59:47 -0600 as excerpted: |
2 |
|
3 |
> a significant change is taking place with several upstreams that will |
4 |
> affect us in gentoo[. Boot-critical components such as Udev, kmod, |
5 |
> etc], are advocating a major change to the locations where binaries |
6 |
> and libraries are stored on linux systems. |
7 |
> |
8 |
> The goal is to deprecate /bin, /lib, /sbin and /usr/sbin. My |
9 |
> understanding is that they want to move software that is installed in |
10 |
> /bin, /sbin and /usr/sbin to /usr/bin. Also, they want to move |
11 |
> everything from /lib to /usr/lib. |
12 |
|
13 |
> If we migrate everything off of the root fs to /usr, all of those |
14 |
> solutions become moot. On the other hand, if we don't migrate, |
15 |
> we run the risk of eventually having our default configuration |
16 |
> not supported by upstream. |
17 |
> |
18 |
> I see three options: |
19 |
> |
20 |
> 1) Start migrating packages along with upstream[. Have separate /usr |
21 |
> users] start using an initramfs [as previously discussed onlist]. |
22 |
> |
23 |
> 2) Combine the sbin and bin directories both on the root filesystem and |
24 |
> in /usr by moving things from /sbin to /bin and /usr/sbin to /usr/bin. |
25 |
> |
26 |
> 3) Try to maintain things the way they are as long as possible. |
27 |
> |
28 |
> Whether or not I like what is happening personally, I think we should |
29 |
> consider the first option, because I think it will get more and more |
30 |
> difficult for us to do anything else over time. And we will eventually |
31 |
> find ourselves not supported by upstreams. |
32 |
|
33 |
I'm for #1 (migrate along with upstream) as well. |
34 |
|
35 |
Gentoo has historically been both "light patch", with a policy of staying |
36 |
close to upstream if possible, and "customizer's choice", allowing users |
37 |
far more flexibility than most distros. Keeping both goals in mind, |
38 |
migrating with upstream is ultimately the only viable alternative for a |
39 |
whole host of reasons including both staying close to upstream and simple |
40 |
manpower resource issues. |
41 |
|
42 |
That said, we can continue to try to support a separate /usr as long as |
43 |
possible, while switching new installs to the new way and changing the |
44 |
handbook to document it, preferably as soon as possible. Further, as |
45 |
previously discussed, a near-static bare-minimal initramfs that can be |
46 |
configured and forgotten about for long periods over many kernel upgrades |
47 |
should make the switch as painless as possible at least for "simple" bare- |
48 |
partition installations. |
49 |
|
50 |
|
51 |
As for the switchover, I had already been thinking about it here and thus |
52 |
have a couple ideas I'd very much like to see implemented in portage/PM/ |
53 |
base.eclass that could definitely help, along with a USE flag. I'll call |
54 |
them "migrated-rootfs" and "migrateroot-strict" for purposes of |
55 |
discussion, here, and assume they're both portage features and that |
56 |
migrated-rootfs is also a USE flag |
57 |
|
58 |
FEATURES=migrated-rootfs would set a USE-default for migrated-root-to-usr |
59 |
so that it'd default to ON, and would indicate that a user is an "early |
60 |
adopter" of the new layout, preferring migration as soon as possible. |
61 |
Users could still set the USE flag as desired for specific packages, at |
62 |
least at first, tho at some point it'd probably first be made a profile |
63 |
default, and ultimately profile-masked either on or off. |
64 |
|
65 |
Additionally, FEATURES=migrated-root would expand the collision-protect |
66 |
feature to check for and warn on both same-package and cross-package |
67 |
collisions between related dirs, with all four bin/sbin root/usr dirs |
68 |
checked for name collisions, and both lib dirs (for single lib, |
69 |
additional pairs for multilib) checked as well. |
70 |
|
71 |
Optionally, if implementation is easy enough, have portage simply remove |
72 |
symlinks to identically named files that would otherwise set off the |
73 |
warning. This is a major reason for having it a feature and a USE flag |
74 |
both, since if this is implemented, portage would take preventive action |
75 |
quite apart from whether an ebuild had been updated to use the USE flag |
76 |
or not. |
77 |
|
78 |
FEATURES=migrateroot-strict would make those collision warnings fatal, |
79 |
much like FEATURES=multilib-strict does for its multilib checks. (As an |
80 |
amd64 user who had this feature on for years, until I switched to no- |
81 |
multilib, that's what the idea is based on.) |
82 |
|
83 |
|
84 |
The goal would be to allow early adopter users to set the less strict |
85 |
version and run a --empty-tree @world update, then grep the logs for the |
86 |
warnings it turned on. If none occurred and /usr is either already on |
87 |
the same filesystem or they have the appropriate early-boot measures in |
88 |
place, they could feel reasonably confident about setting up symlinks |
89 |
pointing to the /usr/bin and /usr/lib dirs as appropriate, and could then |
90 |
set FEATURES=migratedroot-strict to ensure it stays "clean", since after |
91 |
that any attempted merge that would collide would be fatal. |
92 |
|
93 |
Alternatively users could just set the strict version and see what |
94 |
breaks, instead of grepping the logs for the warnings. |
95 |
|
96 |
Since this would leverage the code already in place and tested for |
97 |
collision-protect and multilib-strict, cross-package checking should be |
98 |
fairly easy to implement, but same-package checking and/or actively |
99 |
stripping colliding symlinks may involve rather more new code. |
100 |
|
101 |
Zac? Other portage,/PM/PMS folks? |
102 |
|
103 |
-- |
104 |
Duncan - List replies preferred. No HTML msgs. |
105 |
"Every nonfree program has a lord, a master -- |
106 |
and if you use the program, he is your master." Richard Stallman |