[gentoo-dev] Re: rfc: udev-rules.eclass

[Duncan <1i5t5.duncan@cox.net>]

Zac Medico posted on Thu, 12 Jul 2012 00:33:50 -0700 as excerpted:

>>> Couldn't you, on udev upgrade, move everything in /lib/udev to
>>> /usr/lib/udev, and then make the symlink? Seems fairly simple to me,
>>> but maybe I'm overlooking something?
>> 
>> You are overlooking conflicts introduced through moving files without
>> updating vardb.
>> 
>> 
> Maybe that's package manager dependent. I think it should work fine with
> Portage though.

Confirmed.  This is the way amd64 has handled the lib -> lib64 symlink 
(sometimes reversed) for years (which is why the whole FEATURES=multilib-
strict thing was needed to try and keep things straight).  As long as the 
symlink is there, portage will follow the symlink and manage the files 
just fine.

FWIW, a similar trick was used when migrating X-related stuff from 
/usr/X11R6/ to simply /usr/ .  The files were moved up a level into /usr, 
and /usr/X11R6 became a symlink -> . , thus pointing back to /usr/ .   
IIRC, existing package versions still continued to own their /usr/X11R6/
*, the DB wasn't changed.  New versions simply moved directly into /usr/, 
and the problem gradually solved itself until it was down to a manageable 
size for a final push to get the old location out of the tree.  (I just 
checked and it appears nothing owns that symlink on my system, now... 
unless I screwed up my equery|grep... )

Now if the symlink somehow gets lost before all packages have moved their 
paths...

But that trick has been used enough in gentoo, especially in gentoo/
amd64, that every PM should cope with it just fine, or said PM would be 
rather broken.

-- 
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