1 |
Zac Medico posted on Thu, 12 Jul 2012 00:33:50 -0700 as excerpted: |
2 |
|
3 |
>>> Couldn't you, on udev upgrade, move everything in /lib/udev to |
4 |
>>> /usr/lib/udev, and then make the symlink? Seems fairly simple to me, |
5 |
>>> but maybe I'm overlooking something? |
6 |
>> |
7 |
>> You are overlooking conflicts introduced through moving files without |
8 |
>> updating vardb. |
9 |
>> |
10 |
>> |
11 |
> Maybe that's package manager dependent. I think it should work fine with |
12 |
> Portage though. |
13 |
|
14 |
Confirmed. This is the way amd64 has handled the lib -> lib64 symlink |
15 |
(sometimes reversed) for years (which is why the whole FEATURES=multilib- |
16 |
strict thing was needed to try and keep things straight). As long as the |
17 |
symlink is there, portage will follow the symlink and manage the files |
18 |
just fine. |
19 |
|
20 |
FWIW, a similar trick was used when migrating X-related stuff from |
21 |
/usr/X11R6/ to simply /usr/ . The files were moved up a level into /usr, |
22 |
and /usr/X11R6 became a symlink -> . , thus pointing back to /usr/ . |
23 |
IIRC, existing package versions still continued to own their /usr/X11R6/ |
24 |
*, the DB wasn't changed. New versions simply moved directly into /usr/, |
25 |
and the problem gradually solved itself until it was down to a manageable |
26 |
size for a final push to get the old location out of the tree. (I just |
27 |
checked and it appears nothing owns that symlink on my system, now... |
28 |
unless I screwed up my equery|grep... ) |
29 |
|
30 |
Now if the symlink somehow gets lost before all packages have moved their |
31 |
paths... |
32 |
|
33 |
But that trick has been used enough in gentoo, especially in gentoo/ |
34 |
amd64, that every PM should cope with it just fine, or said PM would be |
35 |
rather broken. |
36 |
|
37 |
-- |
38 |
Duncan - List replies preferred. No HTML msgs. |
39 |
"Every nonfree program has a lord, a master -- |
40 |
and if you use the program, he is your master." Richard Stallman |