Description of problem:

When building using CMake an error may occur if '/bin' or '/sbin' is in $PATH. bins and libs directories were moved to '/usr' in the past but '/usr/lib{64}' is still reachable through '/lib{64}'. CMake uses $PATH among (many others resources) to set variables regarding prefixes and paths to others components and packages. When searching for these paths CMake consider '/' as a valid search path if '/bin' or '/sbin' are included in $PATH.

Some packages store its <PkgName>-config.cmake files under '/usr/lib64/cmake/<PkgName>/' and since '/' is in the internal search path list of CMake '/lib64/cmake/<PkgName>' is also reachable. Some variables will be affected by this (e.g. CMAKE_CURRENT_LIST_FILE or CMAKE_CURRENT_LIST_DIR). If these vars are used to infer any kind of PREFIX (collada-dom-devel package make use of this mechanism. See https://bugzilla.redhat.com/show_bug.cgi?id=1057985) '/' will be gotten instead of '/usr' and any content other than libs will not be reachable (e.g. '/usr/include' will be looked up on /include).


Version-Release number of selected component (if applicable):
2.8.12.2

Steps to reproduce:
# mkdir /usr/lib64/cmake/mypkg
# echo "message(${CMAKE_CURRENT_LIST_DIR})" > /usr/lib64/cmake/mypkg/mypkg-config.cmake
$ cd ; mkdir tmp ; cd tmp
$ echo -e "cmake_minimum_required(VERSION 2.8.3)\nproject(mypkg)\nfind_package(MYPKG)"
$ cmake ./


Actual results:
/lib64/cmake/mypkg

Expected results:
/usr/lib64/cmake/mypkg

Additional info:

Possible solutions

* Consider using CMAKE_CURRENT_LIST_XXX vars to deduce prefixes as a bad practice and avoid its use (some different packages involved) 
* Reinforce path search mechanism in CMake to detect this situation.
* May be not really a bug. Removing '/bin' and '/sbin' from $PATH works well.