> Ты пробовал это применять на практике? Да
И да, смена номера коммита приводит к редактированию одной строки. Либо в ебилде библиотеки, либо в ебилде. "Создать ебилд" конечно посложнее.
> после сборки дерево сорцов будет удалено.
нет. после сборки - нет. после установки в систему (ebuild ... merge)
> Он будет поставлен общесистемно
нет. ebuild ... install ставит в песочницу.
Ещё замечание: часть проблем ты описываешь которые суть "смешивание рабочей и сборочной среды". если подразумевать, что сборочная среда (даже в минимальном chroot-воплощении) от рабочей отделена, проблем нет.
> лянь на npm, pip, gem, cargo, quicklisp: они работают, в отличие от тематических оверлеев gentoo.
это вопрос дискуссионный. я видел всякое, например рекурсивные ошибки в gem.
> Я полагаю дело в том, что разработчику проекта максимально упрощается задача создания "пакета", который может быть автоматически скачан вместе со всеми депендансами и собран.
всё верно. но зачастую результатом gem/pip/cargo etc является то, что сборочная среда называется рабочей и отправляется пользователю в продакшен. это как раз то, что как пользователю мне не нравится.
обобщу. ebuild как таковой естественно не даёт законченной среды разработки для разработчика. но подразумевает что "в продакшене" никакой сборочной среды не будет, и эта функция возложена частично на разработчика, частично - на мейнтейнера. в абсолютном выигрыше - конечный пользователь. npm (обобщённо, как символ подхода) даёт разработчику среду разработки и либо среду разработки вкачивает пользователю в качестве дополнительной рабочей, либо полностью обязывает мейнтейнера обеспечить интеграцию в систему.
интересно, что ничего нового в таком подходе нет. каталог /opt для проприетарщиков, которые ничего про систему знать не хотят и валят туда все свои "библиотеки с конкретными коммитами" существует давно. с одной стороны "пакетный менеджер" конечно похвальное усовершенствование провального подхода, но мне лично кажется, что данные усилия достойны лучшего применения.
Хорошим решением я бы назвал такую систему управления исходниками и бинарями, которая бы позволяла решать задачи разработчика и пользователя легко и универсально. Т.е. нечто, что оперировало бы универсальной терминологией, включающей понятия сред разработки, рабочей среды использовало бы разные типы зависимости и при этом было полностью подконтрольно операционной системе вообще и её пакетному менеджеру в частности.
Чехарда с "пакетными менеджерами для каждого языка" даёт тактический выигрыш, но это совершеннейший стратегический тупик. Ну или как вариант - отказ от концепции операционной системы вообще, что-то типа предельного развития концепции qubernetes
