F20 System Wide Change: Change Packaging Guidelines to discourage requires into /bin and /sbin

Colin Walters walters at verbum.org
Tue Jul 16 20:22:17 UTC 2013


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.




More information about the devel mailing list