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

я не про опции. wine на amd64 был(и вроде сейчас тоже) помечен как сломанный.
В той же gentoo wine прекрасно работал на x86_64(просто собранный с -m32 и через 32битные библиотеки). Т.е. либо мантейнеру было лень, либо в freebsd имелись серьёзные проблемы с запуском 32битных приложений с 64битным ядром.

Попадался еще софт, который нормально работал на 32битной фре/линуксе и 64битном линуксе, но на 64битной фре спорадически крэшился. Именно за это люди платят покупая rhel/sles
(пусть даже ценой более древних версий).

> Софт собранный более новым или более старым компилятором тоже может неработать и
> это нормально. У много софта есть тесты используйье их в крайнем
> случае напишите свои.

вы предлагаете взвалить на себя работу мантейнера.

>> Некоторые разработчики(например, любимый некоторыми proftpd) security fix'ы закрывают
>> выходом новой мажорной версии(да еще с релиз-кандидатом).
> Вот поэтому во фре другой.

кто другой? proftpd? в дебиане proftpd заморожен в рамках релиза.

>> Это если бы вам предложили для закрытия имеющейся проблемы с RELEASE/STABLE переехать
>> на CURRENT.
> Вспомните как за 2-е суток ссш дважды ломанули. А что нельзя было
> сразу второй патч выложить ?

ну да, факап debian security team. freebsd от этого не защищена(в любом случае держать хорошего security-спеца как Brad Spengler в команде стоит хороших денег и ). если для вас столь критично, используйте rhel/sles.