RFC (Request for Comments, Запрос на комментарии) - серия документов, публикуемая сообществом исследователей и разработчиков, руководствующихся практическими интересами, в которой описывается набор протоколов и обобщается опыт функционирования Интернет.
Каждая ОС отличается принципами установки отсутствующего в базовом дистрибутиве ПО, хорошая система должна предоставлять пользователю удобный и максимально простой механизм поиска, установки и обновления ПО.
Хороший пример – идея менеджера пакетов, например, synaptic в Ubuntu, однако реализация на основе deb-дистрибутива оставляет желать лучшего. Ставить предкомпилированные пакеты быстро и просто, однако изменить какие-то опции для пакета практически нереально, поскольку сборка из исходников – нудное и безуспешное занятие. Причем такая ситуация характерна практически для всех Linux-дистрибутивов за некоторыми исключениями. Например, в Slackware приветствует компиляция исходного кода программ, а в Gentoo создано некое подобие системы портов настоящей системы – так называемые ebild-ы. Но Linux остается Linux-ом, собрать из ебилдов что-то серьёзное не так то просто, поскольку придуман собственный уникальный аппарат USE-флагов, превративший стройную систему портов BSD в linux-like бардак.
Плохой пример – MS Windows, где никаких средств поиска ПО нет, наиболее популярные источники ПО – подозрительные сайты, т.н. «варезники», торренты, файлопомойки, намного реже sourceforge.net и т.п. В Windows 8 нам обещают «магазин ПО», а зачем он нужен, если есть свободный софт?
В настоящей системе реализовано самый правильный подход к управлению ПО и пользователю предоставляется выбор.
Существует два варианта:
• предкомпилированные пакеты
• коллекция портов.
Пакеты – специальные архивы с расширением tbz (в 4-ой и ниже ветке – tgz) содержащие все файлы уже скомпилированного порта. Установка представляет собой скачивание и распаковку архива. Основные инструменты работы – утилиты pkg_add и pkg_delete для установки и удаления соответственно. Можно ставить как с диска, так и из интернета, указав либо сокращенное имя, или полный url, например для mc:
# pkg_add -r mc
При это автоматически проверяются и, если необходимо, закачиваются и устанавливаются все требуемые зависимости.
Преимущества – быстрота и отсутствие ошибок сборки. Недостатки – невозможность изменить некоторые опции, что очень существенно для некоторых пакетов.
Порты – некая систематизированная, упорядоченная и однотипная по структуре совокупность файлов, позволяющих компилировать ПО самостоятельно из исходного кода. Каждый порт содержит список url для загрузки архива с исходниками, описание порта (кстати, описания нет в gentoo), Makefile и списком файлов, принадлежащих порту. Ставится порт (например, тот же mc) так:
# cd /usr/ports/misc/mc
# make install clean
После make можно писать различные опции, но это не так важно для нас. Дерево портов разбито по категориям (правда, на мой взгляд, не всегда корректно – сравните net и net-mgmt). По портам возможен поиск, можно сделать html-описание. Порты можно собирать без установки, удалять, переустанавливать. Также их можно централизовано обновлять с помощью порта portupgrade-devel. Существуют мета-порты, объединяющие несколько отдельных портов (например, lang/php5-extension). В некоторых портах предусмотрен диалоги конфигурации, в которых можно задать некоторые опции для configure. Порты также собираются со всеми необходимыми зависимостями, которые можно посмотреть заранее.
Преимущество системы портов – огромная гибкость и, вместе с тем, удивительная простота в работе. Вам полностью доступна вся мощь сборки из исходного кода без необходимости вручную писать пятиэтажные списки аргументов для configure. Существенным недостатком портов являются «несовершенные» snapshot, т.е. в конкретном snapshot может не собираться какой-то конкретный порт. В принципе такой порт можно поставить из пакета, но, если этот порт требуется, как зависимость для сборки другого порта, то собрать такие порты не получится. В системе будет иметь место гибрид из пакетов и портов, а это практически исключает возможность нормального корректного обновления портов в будущем.
Из сказанного выше сформулирую некоторые рекомендации.
1.Если планируется погоня за свежими версиями, ставьте ПО исключительно из портов, и регулярно (раз в месяц) обновляйте коллекцию портов и сами установленные в системе порты. Обновление за 1-2 года как правило обновит далеко не всё и вызовет массу проблем.
2.Если надо поставить немного софта, от сервера требуется разовая настройка, проще ставить из пакетов, собрав редкие специфичные приложения из портов. Если его не трогать – будет работать вечно.
3. Если у вас десктоп – комбинируйте пакеты с портами. Врядли существует такой snapshot, который позволяет без ошибок скомпилировать всё, что нужно на десктопе. Обновления на десктопе практически не реальны. поставьте себе цель – собрать всё что необходимо без принципиальных конфликтов. Сборка Gnome со всеми зависимостями на современном ПК занимает до суток, причем вам необходимо будет периодически отвечать в диалогах конфигурации портов.
4. На «живых» серверах, от которых может потребоваться новый функционал, лучше придерживаться сборки только из портов.
Что нельзя делать:
1. Не пытайтесь без острой необходимости удалять пакеты с устаревшего (5-6 лет) сервера. Дерево портов там практически мертвое, а версию pkg можно не угадать. К тому же велика вероятность снести системные библиотеки, которые потом придется мучительно пересобирать вручную. Лучше использовать make deinstall, но это возможно только в случае установки из портов.
2. Не злоупотребляйте обновлениями портов на работающем ответственном сервере. Это долгий и нудный процесс, который требует строгого контроля и возможности оперативно исправить положение.
В принципе в на ftp-серверах freebsd есть наборы пакетов и исходники портов практически для всех версий системы. Кроме того, никто не отменял поиска в google, где можно практически всегда найти ссылку для скачивания нужного для сборки файла. Но на правильно настроенном сервере необходимость в этом не должна возникать.