пользователям source-based дистрибутивов

В единственно нормальном source-based дистрибутиве NixOS нет таких проблем.

В остальных приходится костылять. В LFS я собираю по возможности в виде flatpak пакета, зависимости для сборки, например rust при этом ставятся как расширение flatpak SDK и потом удаляются.

• пихаете все это непотребство в систему
• используете бинарные сборки
• еще какие варианты

пихаете все это непотребство в систему?

да

отказываетесь от использования в принципе?

да

используете бинарные сборки от разработчика?

не только от разработчика

еще какие варианты?

да

В единственно нормальном source-based дистрибутиве NixOS нет таких проблем.

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

это по приоритетности?

не только от разработчика

блин, ты меня переплюнул…

pkg_add package

TL;DR: использую готовые бинарные пакеты. Из портов компилил последний раз лет 15 назад.

песочницы начиная с /opt и даже /home/$username помогут мсье независимо от его дистропредпочтений :)

с идиотскими зависимостями для сборки софта??

что это?

то ты или руст вынужден в систему пхать

Если тебе что-то надо «пихнуть» для сборки и потом оно гарантированно и чисто после сборки удалиться - это не проблема. Если же это что-то должно остаться в системе и после сборки, просто для работы собранного - вот это проблема.

С flatpak или nix мне руст нужен только для сборки. Потом он в системе зачем? После сборки он сносится в NixOS при чистке мусора вообще автоматом - он не рантайм зависимость, а с flatpak сносится вручную.

который хрен оторвешь

Вообще вот сочетание этих трех слов - это моргающий индикатор того, что t184256 называет «импотентный пакетный менеджер».

Нормальный пакетный менеджер должен мочь оторвать что угодно. Даже руки (и отстрелить ноги).

У меня свежий source-based опыт был со созданием среды разработки на маке, которая бы не сжирала все ресурсы. Кастомная инсталляция Homebrew, которая вынудила меня попересобирать много пакетов (из-за того, что префикс другой).

Непотребства было много, хотя бы потому, что мне там нужен был ansible, а он в более новых версиях почему-то хочет rust. А из-за того, что префикс кастомный, то и rust надо было пересобирать.

К данной проблеме отношусь так, что это дух времени. Ну, мне много чего не нравится, но в одиночку я революцию не сделаю. Пойдешь на HackersNews, там каждую неделю какой-то манифест о том, как все плохо, все сочувствующе кивают головами, и никто ничего не делает.

Возможно, когда-то программистов за такое расточительство и головотяпство в построении деревьев зависимости начнут карать. А сейчас никаких стимулов думать об этом нет, вот всем и похер.

Проблема - это когда ненужное для работы не нужно, но при автоматизации сборок новых версий нужного у тебя /usr/local оказывается загаженым как ни один общественный дальняк

Ага, покажи мне пакетный менеджер, который вправляет гемморой разработчикам за необоснованные зависимости

Разве Firefox'y не нужен Rust для сборки из сорцов?

/usr/local

Это и есть общественный дальняк. Зачем вообще так делать?

Ага, покажи мне пакетный менеджер, который вправляет гемморой разработчикам за необоснованные зависимости

Я не понимаю какую практическую проблему ты пытаешься решить. У тебя сервер для CI? Или что?

Нужен конечно. Для сборки. Для работы не нужен.

Свой дистр

Если тебе что-то надо «пихнуть» для сборки и потом оно гарантированно и чисто после сборки удалиться - это не проблема

Это проблема. Ведь собирать надо не один раз, а каждый раз, когда пакет обновляется. И сборочные зависимости тоже нужно собирать. Ты хоть раз видел, сколько компиляется раст или шланг?

Так он и должен оставаться в системе, если предполагается обновление Firefox, не удалять же его и ставить перед каждым обновлением.

И я не пытаюсь решить проблему, просто хочу собрабь опыт

Отсюда и различные варианты

AUR(точнее автоматизаторы работы с ним) умеет доставлять зависимости и подтирать потом, для iosevka нужны nodejs и jvm! Rust годно и нужно, ждем gccrs.

Свой дистр

На базе LFS делаешь? Лично я не вижу смысла сейчас делать дистры без контейнеризации всего, по принципу /usr/local. Будет свалка.

Нужна сборка в контейнерах.

Каждый решает для себя - всё устраивает в сборке программы от дистростроителя, используй бинарник, не устраивает - собирай из сорцов для себя, но тяни ещё зависимости для сборки (которые могут быть так же бинарными).

а каждый раз, когда пакет обновляется

Ну скачается все опять, интернеты нынче жирные. А у кого не жирные - у тех винты жирные.

И сборочные зависимости тоже нужно собирать

В генте - нужно. В нормальном source based (NixOS) не нужно. Ну так зачем мучиться с гентой?

хоть раз видел, сколько компиляется раст или шланг?

Не представляю зачем мне его собирать, даже в source based дистрибутиве.

не удалять же его и ставить перед каждым обновлением

Почему нет, если это «засоряет систему»?

но тяни ещё зависимости для сборки (которые могут быть так же бинарными)

Вот именно. Их совсем не обязательно собирать.

Сразу видно прожженого слакварщика.

Практически не знаком NixOS, в нём так же можно использовать вперемешку бинарные\сорцовые пакеты?

О, это надо глянуть

Увидел твой ответ позже, как написал комментарий, в общем как в Calculate Linux, можно пользовать бинарные пакеты и сборки из сорцов.

в нём так же можно использовать вперемешку бинарные\сорцовые пакеты?

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

Да, получается как в кальке, удобно в этом плане.

В единственно нормальном source-based дистрибутиве NixOS нет таких проблем.

Там реализовали установку build-зависимостей в tmpfs?

Собирать в tmpfs надо или зависимости в tmpfs ставить?

Ну вообще в gentoo можно так же при желании. Надо только какой нибудь бинарный репозиторий подключить, например от кальки. Но это только при условии совпадения USE-флагов у бинарного пакета и в системе, что не всегда возможно.

а вот возможно ли в nixos что то подобное?

ты ошибаешься, возможна NixOS (где нет понятия «пихать в систему» и билддепы ни с чем не интерферируют)

Собирать в tmpfs и так все умеют.

При установке из исходников приходится либо оставлять build-зависимости в системе мёртвым грузом, либо лишний раз насиловать SSD, устанавливая их каждый раз.

Да, тривиально.

Там нет «в системе». Как и любой софт в NixOS они лежат так, что никому не мешают, пока однажды гарбадж-коллектор их не соберёт.

ИМХО в общем случае не хватает ещё варианта «собираете на отдельном хосте».

Мой личный ответ: NixOS, никак не борюсь, билдхост с диском АЖ 250ГБ собирает мне будущую систему заранее, сборщик мусора сам подметает, а понятие «мусор в системе» невозможно по построению.

Как и любой софт в NixOS они лежат так, что никому не мешают, пока однажды гарбадж-коллектор их не соберёт.

Я сейчас не про эту проблему вообще. Лежат на том же диске, что и все остальные пакеты — значит, уже в системе. А нужно чтобы они в tmpfs ставились.

А по умолчанию там с какими флагами собирают?

Ну например polkit завожу старый в систему чтобы spidermonkey не собирать.
Где-то приходится править в ебилдах зависимости. В самих исходниках обычно лишняя фигня отключается

Лежат на том же диске, что и все остальные пакеты — значит, уже в системе.

Нет. Напрягись и услышь это.

А нужно чтобы они в tmpfs ставились.

Лол, штоб у меня на каждом нетбуке было сто гигов tmpfs под билддепы. И все терпение мира, чтобы после перезагрузки их заново перекачать.

Выдыхай, бобёр, ты хочешь как минимум непрактичного.

Зачем ставить что-то в tmpfs, чтоб после перезагрузки их опять собирать?

сомневаюсь в этом.