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

Подскажите как корректно отредактировать /etc/login.conf что бы русский остался, но все сообщения были английские? Как правильно указать LC_MESSAGES сейчас секция выглядит так:

Я чо-то упускаю? clickhouse же давно в портах.
Правда, года три назад собранный бинарь выпадал в осадок, но потом починили.
Зависимостей у него, конечно, хренова гора...

Я не только про clickhouse, я про ситуацию в целом. Много "тяжёлых" пакетов, которые из исходников не особенно пообновляешь: я бы предпочёл chromium без синтезатора речи и прочих излишеств, а libreoffice без spellchecker'а, gstreamer'а и прочих *sql и ldap.                                                               Много портов с кучей опций, про которые надо помнить при развёртывании: у rrdtool отключить graph, а у asterisk вообще почти всё, у freeradius включить условно ldap, pgsql и experimental, и так далее.
Есть же хорошие примеры: nginx попилили хотя бы на 3 варианта, у postgresql вынесены отдельно -docs/-contrib/-pl*, есть vim-console, mc-nox11, куча прочих -lite.

А конкретно для ch было б неплохо:
* почистить лишние депенды, не нужные в продакшне (и сделать условными для TEST),
* побить пакет на -core, -odbc (может, ещё чего), а если хочется совместимости, сделать метапорт clickhouse.
Никаких причин, чтобы разные варианты/субпакеты были частично разломаны, я тут не вижу. Distfile один и тот же. Если уж ch не умеет configure и частичную сборку, пусть собирается целиком, а нужное цепляется в pkg-plist.

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

Много чего не нравится.

Во-первых, тенденция пихать в самый сраный проект кучу сомнительных зависимостей. Это в огород разработчиков. Например, у ch пихтоновский lxml в исходниках вообще не встречается, а termcolor -- только в тестах, но зачем-то ещё и в докер-образы засовывается (которые применительно к фряхе как той собаке пятая нога). У ch ещё и configure (или аналог) отсутствует, ненужное не поотключаешь.

Во-вторых, пихать сомнительные зависимости в порт. Это в огород портеров. Скажем, зачем clickhouse'у googletest, если в опциях тесты выключены вообще? А expect+tcl+сотоварищи?

В-третьих, почему не побить проект на несколько пакетов? Скажем, вынести тот же odbc-интерфейс. Тоже к портерам. Тут, конечно, надо не переборщить и не дробить, как некоторые, совем уж на атомы (типа sqlite: либа отдельно, бинарь отдельно, .h отдельно, маны отдельно). На крайний случай, опций досыпать (но тогда пакетная установка отпадает).

В-четвёртых, нихуя неочевидно, зачем именно эта гора мусора нужна. Для сборки? Для рантайма? Для самого пакета или для зависимости седьмого колена? Отслеживать вручную каждый сомнительный из нескольких сотен -- не смешно нифига. Добавить бы такую фишку в порты (типа make missing-tree) и чтоб pkg install показывал -- цены б ей не было. Взять тот же graphviz. Может, достаточно у какой-то зависимости по дороге галочку снять. Может, потом подумать, не побить ли тот зависимый пакет на помельче.

В-пятых, дефолтные опции в портах. Тоже порой не понимаю, чем портеры руководствуются.

Может, я погорячился, но наболело. Прастити :)

Ну а тот, что в портах, тянет пару десятков run и несколько сотен build

у кликхауса практически нет зависимостей, он восновном статитечски собран, там только libc libmath и бротли в зависимости у него

Есть все-таки возможность обновлять STABLE без сборки ядра и мира? Слишком это долго на каждой машине :( Из бинарников как релиз вполне-бы устроило

freebsd-update ?

Есть все-таки возможность обновлять STABLE без сборки ядра и мира? Слишком это долго на каждой машине :( Из бинарников как релиз вполне-бы устроило