Это то самое шаманство, которым так любит гордиться любой гентушник, не признавая средств автоматизации в виде cl-update ;) А тут за вас ещё и настройки по одному клику изменятся. Что вы получите в итоге? Часть пакетов начнёт собираться из исходников, т.е. по факту время на обновление увеличится со считанных минут до считанных часов (добавьте сюда ещё и удаление лишних языков). Из выделенного при установке 10 Гб. раздела освободится 100 Мб, производительность же останется на прежнем уровне. Ладно, если бы пользователь сам это делал, осознавая свой выбор. Тогда сыграл бы субъективный фактор, что ему это действительно нужно. В этом же случае после нескольких дней работы назреет устойчивое желание откатиться назад.

Broadcom, cups, hplip и т.д., как определить, что не будет использоваться ни при каких обстоятельствах?

Alexander Tratsevskiy wrote:

Это то самое шаманство, которым так любит гордиться любой гентушник, не признавая средств автоматизации в виде cl-update ;) А тут за вас ещё и настройки по одному клику изменятся. Что вы получите в итоге? Часть пакетов начнёт собираться из исходников, т.е. по факту время на обновление увеличится со считанных минут до считанных часов (добавьте сюда ещё и удаление лишних языков). Из выделенного при установке 10 Гб. раздела освободится 100 Мб, производительность же останется на прежнем уровне. Ладно, если бы пользователь сам это делал, осознавая свой выбор. Тогда сыграл бы субъективный фактор, что ему это действительно нужно. В этом же случае после нескольких дней работы назреет устойчивое желание откатиться назад.

Broadcom, cups, hplip и т.д., как определить, что не будет использоваться ни при каких обстоятельствах?

На сколько я помню, broadcom не производит сторонних модулей, так что остаются лишь встроенные сетевухи, так что можно получить текущий используемый модуль Wi-Fi и его обновлять, а по поводу гентушников не совсем понял.

Да и к слову, LibreOffice у меня и так из исходников почему-то собирается, что занимает уйму времени, почему не знаю.

Проблема в том, что исключение зависимостей часто ведёт к изменению USE флагов. Изменение флагов к обязательной пересборке пакетов из исходников.

Когда ты используешь BB (binary-based) бинарный профиль, готовые пакеты, ты, грубо говоря, расписываешься в том, что граждане дистростроители знают что с чем собирать, ты им в этом доверяешь, вопрос "а почему A тянет за собой B" не задаёшь и на предмет зависимостей общаешься с дистростроителями только и исключительно при наличии их явных косяков - багрепортами. Хорошо сделанный бинарный дистр гарантирует, что ты можешь ставить и удалять какой угодно софт, и зависимости нигде не будут поломаны, зациклены или оставаться "потеряные" пакеты, которые сами по себе тебе не нужны, ни одному из установленных пакетов не требуются.

Когда ты используешь SB (source-based), ты как бы декларируешь, что сам лучше знаешь что с чем собирать, и дистростроители тебе просто дают набор инструментов для отслеживания зависимостей, поиска потеряных(orphaned, "осиротевших") пакетов и т.д. Инструменты дадут, но ты у ж сам.

FreeBSD Calculate, являясь SB (и реализовано это через систему портов портежей), тем не менее предоставляет возможность ставить бинарными пакетами. При аккуратности и чётком понимании можно даже "смешивать и взбалтывать", оба подхода, благо обобщённое управление есть - это pkg-ng с командами pkg * emerge. Хотя для обучения лучше конечно выбрать что-то одно: и если уж ставишь бинарями, то претензий "а почему прилетело XXX" быть не должно.
(c)