Read about the FHS (while its use is evolving), it is still a good reference). Typically, stuff installed in secondary /usr/{bin,lib,...}, and primary (/bin,...

Read about the FHS (while its use is evolving), it is still a good reference). Typically, stuff installed in secondary /usr/{bin,lib,...}, and primary (/bin,...) hierarchies is handled by package managers, which handle conflicts in a bulletproof way. This means that if you install some files manually that happen to be in use by some package, the system won't know about it, and if not and you install a conflicting package afterwards, the package manager will barf at you because there's a file there already. Also it will be hard to know which files to remove (e.g when upgrading/uninstalling the manually compiled software) save for a rare few that provide a make uninstall or actually reinstalling, capturing stdout and looking for which files got installed. To sum it up it is a problem of tracking and consistency. In short, if you ever want to build software yourself there are two possible destinations, and hence two solutions: - put it in primary/secondary hierarchy: make a package for your package manager - put it in tertiary hierarchy (/usr/local) or optional software (/opt/your_software_name): use PREFIX/--prefix or whatever idiom the build system uses for controlling where the files will end up. More often than not with tertiary you don't even need to set up PATHs and include directories (think library and dependencies) and whatnot.