Как сохранить чистую папку / lib?

OSX не использует /lib (у него есть /Library, например). CentOS использует /lib для своих системных библиотек (или /lib64 для 64-битных систем), и really ожидает найти их в этом месте. Если вы уберете это, вы можете сломать свою систему.

Большинство людей устанавливают непакетные программы в /usr/local (/usr/local/bin, /usr/local/lib и т.д.), или даже в какой-нибудь необычный каталог, чтобы избежать конфликта с пакетами на разных системах.

Большинство Unix-подобных систем (включая эти) используют /bin, и, возможно, не оценят хорошей очистки.

Есть ли способ держать папку /lib в чистоте?

В природе каталогов lib в системах типа Unix/Linux не заложено быть "чистыми". Они являются совокупными каталогами, в которых хранятся все библиотечные файлы, необходимые вашей системе.

Они могут содержать библиотеки, которые вам больше не нужны. Надлежащим инструментом для принятия решения и решения этой проблемы является менеджер пакетов.

Это, очевидно, yum+ rpm на вашей коробке CentOS 6.

На OS X все не так однозначно. Для OS X существует куча менеджеров пакетов, некоторые встроенные, некоторые сторонние:

• Вероятно, наиболее часто используемым методом управления связью между приложениями и их зависимыми библиотеками в OS X являются пакеты .app, которые пользователь перетаскивает в /Applications или ~/Applications для установки, и перетаскивает в Корзину для удаления.

  В Finder пакеты приложений OS X выглядят и ведут себя как отдельные файлы, но на самом деле это каталоги, полные файлов, которые могут содержать, помимо прочего, зависимые библиотеки. (Щелкните правой кнопкой мыши на одном из них и выберите "Показать содержимое пакета", чтобы увидеть это). Таким образом, когда вы "удаляете" приложение, перетаскивая его в Корзину, вы удаляете не только основной исполняемый файл, но и все его специфические библиотеки и некодирующие ресурсы.

  По сути, именно так работает Mac App Store. В этом смысле программа App Store выполняет роль yum или apt-get: загружаемые ею файлы .app - это управляемые пакеты, мало чем отличающиеся от RPM на вашей CentOS.

  Я подозреваю, что это вполне соответствует вашему желанию: исполняемый файл, библиотеки и другие зависимости исполняемого файла хранятся в собственном подкаталоге, который легко удалить, если он больше не нужен.

• Есть также старые pkg* инструменты, но они постепенно выходят из моды уже много лет. Это то, что вы используете, когда открываете файл .dmg и получаете внутри файл .pkg или .mpkg, который устанавливается при двойном щелчке.

  Эти инструменты разбрасывают файлы по всей системе, и нет простого способа их удаления. Следовательно, существует множество сторонних инструментов и ручных методов для удаления пакетов OS X pkg.

  Следовательно, я не могу рекомендовать вам использовать файлы пакетов OS X, если вашей целью является точное управление набором файлов, установленных в вашей системе.

• Существует три основные системы управления пакетами сторонних производителей для OS X: Fink, MacPorts и Homebrew.

  Если пакеты приложений не подходят для ваших случаев использования, я бы рекомендовал вам использовать пакеты из одного из этих репозиториев. Homebrew кажется наиболее популярным на сегодняшний день.

  Эти пакетные системы ведут себя как менеджеры пакетов в системах Linux и BSD, поскольку вы можете устанавливать, обновлять и удалять пакеты с помощью простого интерфейса командной строки.

Я работаю с ИТ, чтобы установить некоторые вещи, такие как GCC. Пакет yum не доступен для последней версии GCC.

Вам не следует использовать CentOS, если вам нужна последняя версия GCC. Весь смысл CentOS в том, что версии пакетов остаются стабильными с момента, задолго до выхода первого релиза ОС (часто за 6 месяцев или больше!) и до окончания срока службы этого релиза. Эта прикрепленная на место версия затем получает backported исправления в течение всего срока поддержки ОС. Это один из способов обеспечения стабильности дистрибутива.

Есть только один официальный способ получить более новую версию GCC для CentOS 6: перейти на CentOS 7.

Если у вас есть веские причины пренебречь этим советом, можно собрать альтернативную версию GCC, которая устанавливается параллельно с версией, предоставляемой ОС. Вероятно, самый простой способ сделать это - использовать опцию --prefix в сценарии configure при сборке вашего собственного GCC. Например:

$ ./configure --prefix=/usr/local/gcc-5.3

Когда вы позже скажете make install, все полученные двоичные файлы, библиотеки и некодирующие ресурсы будут помещены под этот префикс каталога, подобно тому, как работают пакеты приложений Mac OS X.

Сделав это, вы можете упаковать свой собственный GCC как RPM. Документация находится в свободном доступе, а примеры можно найти в Интернете. Или вы можете обнаружить, что кто-то другой уже сделал это, и вы можете просто использовать его RPM.