I have been installing libraries for use with c programs. Is there a way to keep the /lib folder clean? Can I use subdirectories, links, etc to manage this? It's getting pretty cluttered, I'm not sure I'll be able to adequately remove a specific library if I want to remove it later.
Same question goes for /bin.
I am on OSX at home and also CentOS6 at work, where I am working with IT to install some things like GCC. A yum package is not available for the latest GCC.
Is there a way to keep the /lib folder clean?
It is not in the nature of the lib directories on a Unix/Linux type system to be "clean." They are aggregate directories, collectively holding all of the library files that your system needs.
They might contain libraries that you don't need any more. The proper tool for deciding and coping with that is a package manager.
That's clearly yum+rpm on your CentOS 6 box.
On OS X, it's not so clear. There are a bunch of package managers for OS X, some built-in and some third-party:
Probably the most commonly used method for managing the pairing between applications and their dependent libraries on OS X are .app packages, which the user drags into /Applications or ~/Applications to install, and drags to the Trash to uninstall.
In the Finder, OS X app packages look and behave like single files, but they're actually directories full of files, which may contain dependent libraries, among other things. (Right-click one and select "Show Package Contents" to explore this.) Thus, when you "uninstall" the app by dragging it to the Trash, you're not just removing the main executable, but also all of its app-specific libraries and non-code assets.
This is basically how the Mac App Store works. In that sense, the App Store program is filling the role of yum or apt-get: the .app files it downloads are managed packages, scarcely different from RPMs on your CentOS box.
I suspect this meets your desired state admirably: the executable, libraries, and other dependencies of the executable are held in their own subdirectory, easily removed when not wanted any more.
There's also the old pkg* tools, but those have been slowly going out of style for years. This is what you're using when you open up a .dmg file and get a .pkg or .mpkg file inside which installs when you double-click it.
These tools scatter files all over your system, and there is no easy first-party way to uninstall them. Consequently, there are many third-party tools and manual techniques for uninstalling OS X pkg packages.
Consequently, I can't recommend that you use OS X package files if your goal is to precisely manage the set of files that are installed on your system.
There are three major third-party package management systems for OS X: Fink, MacPorts, and Homebrew.
If app packages are not appropriate for your use cases, I'd recommend that you use packages from one of these repositories. Homebrew seems to have the most traction today.
These package systems behave like package managers on Linux and BSD systems in that you can install, upgrade, and remove packages from a simple command line interface.
I am working with IT to install some things like GCC. A yum package is not available for the latest GCC.
You should not be using CentOS if you need the latest GCC. The whole point of CentOS is that package versions remain stable from a time well before the initial OS release (often 6 months or more!) clear through the end-of-life for that release. That pinned-in-place version then gets backported fixes through the support lifetime of the OS. This is one of the ways such as distribution gets its stability.
There's really only one official way to get a newer version of GCC for a CentOS 6 box: upgrade to CentOS 7.
If you feel you have a good reason to disregard that advice, it is possible to build an alternate version of GCC that installs in parallel with the OS-provided version. Probably the simplest way to do that is to use the --prefix option to the configure script when building your custom GCC. For example:
$ ./configure --prefix=/usr/local/gcc-5.3
When you later say make install, the resulting binaries, libraries and non-code assets will all be placed under that directory prefix, much like the way Mac OS X app packages work.
Having done that, you could then package your custom GCC as an RPM. The docs are freely available, and examples abound online. Or, you might find that someone else has already done this, and you can just use their RPMs.
lib directories on a Linux box really aren't any different from c:\windows\system32, the GAC, c:\Program Files\Common Files, and other dumping grounds in Windows. I think you'll find that the more time you spend with Mac and Linux package managers, the more annoyed you get by the slowest dialog box in Windows and the pitiful Windows 8/10 app store.
– Warren Young
Feb 26 '16 at 11:34
OSX doesn't use /lib (it has /Library for instance). CentOS uses /lib for its system libraries (or /lib64 for 64-bit systems), and really expects to find them in that location. If you clean it up, you might break your system.
Most people install non-packaged programs in /usr/local (/usr/local/bin, /usr/local/lib, etc), or even some unusual directory to avoid conflict with packages on various systems.
Most Unix-like systems (including these) use /bin, and would perhaps not appreciate a good cleaning.
/liband/binaren't yours to muck with. For programs and libraries that you compile yourself and install under/usr/localor your home directory, see Keeping track of programs – Gilles 'SO- stop being evil' Feb 25 '16 at 21:35