О портах и пакетах

[filonov]

Поскольку тема вызвала широкий резонанс
обобщу свое мнение.

1. Существенная часть претензий от линуксоидов с BSD-шной системе портов, сводятся к тому, что FreeBSD - не Linux. С этим ничего поделать нельзя, да и не стоит оно того imho. Изготовление очередного линуксоклона FreeBSD попросту добьет.
2. Система портов-пакетов безусловно нуждается в значительной переработке. 

Остановимся подробнее на втором вопросе:

• На данный момент пакеты пригодны лишь на начальном этапе установки системы, и в ряде специфичных конфигураций.
• Для более широкого и надежного использования пакетов - совершенно необходима проверка надежности источника пакетов. Т.е. пакеты должны быть подписаны, и подпись должна проверяться при инсталляции. Также необходима возможность задавать свои источники пакетов, с соотвествующей проверкой. (PACKAGEROOT в нынешнем виде не позволяет сопоставить публичный ключ репозиторию).
• @pkgdep безнадежно устарел и непригоден для корректного разрешения зависимостей, там, где они могли бы быть разрешены корректно.
• C зависимостями в портах чуть лучше, но также ситуация далека от идеала.

В качестве одного из путей решения проблем предлагается дробление пакетов.
Сама идея уходит корнями в линукс, и имеет свои достоинства и недостатки.

Идея покромсать пакет packet на packet, packet-devel, packet-doc, packet-etc... достаточно очевидна, но является ли она единственно возможной?

Пакетная система - плоская, она состоит из пакетов, пакетов и пакетов. Ничего кроме пакетов.
Однако, как быть если программа prog допускает N опций сборки, prog.1 prog2 ... prog.N ? Плодить N! пакетов пока что не додумались даже самые отмороженные линуксоиды, и политика сводится к "жрите что дают". Что делает к примеру RH-овский exim малоприменимым, поскольку он собран со всеми доступными sql-клиентами сразу, что никому не нужно в 99% случаев. Однако возможность указать зависимость от prog.i достаточно ценна, чтобы ею так просто пренебрегать.
 Решение мне видится в введении модульных пакетов. Т.е. к плоской, 1-уровневой системе пакетов, добавить 2-е измерение:

• система состоит из пакетов
• пакеты состоят из модулей.
• набор инсталлируемых модулей задается при инсталляции пакета
• модули инсталлируются-деинсталируются по частям - не затрагивая других модулей
• при сборке из портов потенциально возможна инкрементальная сборка модулей
• модули могут быть взаимоисключающими.  mc.slang не может быть одновременно с mc.ncurses
• зависимости могут быть как к пакетам, так и в модулям в них. Т.е. prog -> gettext.lib , но при этом prog не требует gettext.util

Достоинства:

1. Более жесткий контроль целостности. Все модули ставятся из одного пакета. Ситуация "prog-v1 у нас есть, prog-v1-devel по прошествии времени затерялся, а prog-v2 не работает так как нам надо" попросту невозможна.
2. Гибкость в настройке. В нынешнем виде ни порты, ни линуксовые пакеты, не позволяют задать для модульных програм - какие из модулей собрать динамически, а какие статически. А такая необходимость безусловно существует - см холивары "я собираю апач руками статиком чтобы выиграть 0.0003ms"
3. Альтернативные зависимости хорошо покрываются мета-портами. К примеру у нас есть мета-порт www/apache который предлагает альтернативные модули 
   • apache.13 -> www/apache13
   • apache.13ssl -> www/apache13-ssl
   • apache.20 -> www/apache20
   • apache.22 ->www/apache22
   •  ...
   что позволяет задать зависимость lang/php от www/apache. А уж какой из апачей будет использован - определится в конкретной инсталляции.
4. Модульность хорошо ложится на base system. У нас одна base system, но в ней есть хорошо выраженные модули  (ядро, bind,sendmail, etc). При этом можно легко описать, что emulators/linux_base-f10 зависит от base.linux. Так же слегка упрощается работа с security advisory - "приложите патчи и пересоберите base.bind"