| 1 |
All, |
| 2 |
|
| 3 |
I thought that since the usr merge is coming up again, and since I lost |
| 4 |
track of the message where it was brought up, I would open a |
| 5 |
new thread to discuss it. |
| 6 |
|
| 7 |
When it came up before, some were saying that the /usr merge violates |
| 8 |
the fhs. I don't remember the specifics of what the claim was at the |
| 9 |
time, (I'm sure someone will point it out if it is still a concern). |
| 10 |
|
| 11 |
I don't think creating usr merged stages would be that difficult. I |
| 12 |
think it would just be a matter of creating a new version of baselayout |
| 13 |
that puts these symlinks in place: |
| 14 |
|
| 15 |
/bin->usr/bin |
| 16 |
/lib->usr/lib |
| 17 |
/lib32->usr/lib32 |
| 18 |
/lib64->usr/lib64 |
| 19 |
/sbin->usr/bin |
| 20 |
/usr/sbin->bin |
| 21 |
|
| 22 |
Once that is in place in a new baselayout, I think portage's colission |
| 23 |
detection would be able to catch files that had the same names and were |
| 24 |
originally in different paths when building the new stages. |
| 25 |
|
| 26 |
I put some thought also in how to nigrate live systems, and I'm not sure |
| 27 |
what the best way to do that is. I wrote a script, which would do it in |
| 28 |
theory, but I haven't tested because I only have one system and if |
| 29 |
it breaks it the only way back would be to reinstall. |
| 30 |
|
| 31 |
The script is attached. |
| 32 |
|
| 33 |
|
| 34 |
Thoughts on any of this? |
| 35 |
|
| 36 |
William |
Archives