On Tue, 2013-07-16 at 12:18 -0700, Toshio Kuratomi wrote:
<nod> I think that the best course of action would to rethink UsrMove as UsrMerge which I would then take to the rest of the FPC as getting rid of the prohibition on packages listing /bin, /sbin/ lib, /lib64 as the location in the file.
Yes.
- Have package maintainers patch upstreams to use /usr/{bin,lib,[..]} instead of /{bin,lib[...]} (for instance, shebang lines)
This is extreme, almost entirely pointless busywork. The cost of the /bin -> usr/bin symbolic link on the filesystem is very very small. Let me phrase it this way: I doubt anyone can come up with a workload where the symlink traversal is a measurable part of a real application. Particularly when compared to the other inefficiencies and outright buggy crap[1] in the vast swaths of even core userspace.
- Have packages which traditionally provide /{bin,sbin,possibly lib but I can't think of something in /lib that's actually causing breakage} create Virtual Provides for those older file paths.
Or again, have RPM synthesize them automatically if the build environment has that magical rpmlib(X-Something) that I can't find in a quick search.
[1] Some of that buggy crap is my code; it makes more sense for me to spend scarce engineering time on fixing issues that affect actual real world scenarios than to go on a global search and replace for /bin -> /usr/bin and dealing with the fallout when I later need to backport something to RHEL6 for example. Same applies to everyone else.