> I think they intended this to play out like SystemD/logind - Red Had maintainers will only care about merged /usr and if you want to use anything they have th

> I think they intended this to play out like SystemD/logind - Red Had maintainers will only care about merged /usr and if you want to use anything they have their hands in you better adapt. The argument this article seems to make is that you can essentially hard code the paths to binaries in your build system, because /lib is /usr/lib, /bin is /usr/bin (from build script point of view it doesn't matter which is symlink to which). It seems to be saying that your build systems no longer need to search for the libraries. But that's not true. You still do. And if you search for it then it doesn't really matter where it is. Clearly if you search for `bash` you'll search /bin and /usr/bin. For at least two reasons: 1) Maybe you're running a system that isn't merged. Then it could be in either place. Doesn't matter if RedHat is merged. 2) You'll need to check other locations anyway. Like /usr/local/bin/bash, to support some BSDs. Why does it matter if it's two, three, or $(echo $PATH | sed 's/[^:]//g' | wc -c) paths? And for libraries you may need to search in /opt, and run pkgconfig for any compile and link flags needed. Why does it matter that `pkg-config --libs foo` contains an -L flag? You still need to run it.