>> дык я про то же. а тут контингент с дисфункциями организма при
>> виде работающего gcc. и любитери попенять на время сборки.
> ментейнеры портов тестируют софт на всех опциях и на всех поддерживаемых сейчас
> версиях FreeBSD и архитектурах?

Чего они должны тестировать? Они не тестеры. Мантейнеры обеспечивают сборку ПО, согласно рекомендациям разработчика этого ПО, с теми флагами сборки и зависимостями библиотек, которые обязательны и/или допустимы. Вот такой Use Case они и реализуют на сборочной машине. Собралось, запустилось — обновляют порт в коллекции портов. ВСЁ.

> Я не раз сталкивался с софтом, который хреново работает, будучи собранным чуть
> более свежим/старым gcc, не говоря уже о CFLAGS/CXXFLAGS.

Пппц. На FreeBSD почти весь софт собирается системным GCC 4.2.1. Меняешь флаги сборки у портов — ССЗБ.

>> Ну как-то так. А дальше как ни крути - личное начинается. Личные
>> оценки, личный опыт, личные предпочтения. Мне, как перфекционисту, ближе source-based,
>> а если ещё и вдобавок rolling release это вообще сказка.
> угу. вышел новый релиз софта X, в котором автор решил поменять опции
> конфига или ключи запуска и рабочая система рассыпалась. нет уж, спасибо.

"Система" — это та, которая GNU/Linux? Наверняка рассыпается при обновлении какой-либо либы, так как ABI нестабильно даже в минорных версиях, а читать README, в котором написано, в какой версии ядра и системного окружения программа собиралась и работала, многие забывают.

К счастью, на FreeBSD такое редко встречается — система не может рассыпаться из-за неудачно собранного порта. Зато портированная версия программы спокойно может завершиться с Segmentation fault даже после успешной сборки — просто мантейнер запускал в GENERIC-окружении, а у вас оказался "оптимизированный" обрезок от GENERIC.

> Некоторые разработчики(например, любимый некоторыми proftpd) security fix'ы закрывают
> выходом новой мажорной версии(да еще с релиз-кандидатом).
> Это если бы вам предложили для закрытия имеющейся проблемы с RELEASE/STABLE переехать
> на CURRENT.

CURRENT — это тестовая ветка разработки. Из неё попадают оттестированные подсистемы в STABLE-ветку. Из STABLE путём тщательного трёхмесячного тестирования выпускаются RELEASE. К RELEASE выпускаются отдельные Security Fix'ы: как только обнаружатся дырочки, заплатки сначала попадут в CURRENT, их протестируют разработчики, затем передадут в STABLE для широкомасштабного тестирования, а затем их смержат с RELEASE и выпустят бинарное обновление -RELEASE-pNM.