>> Вы слишком поспешно переходите к выводам. Пакетные системы, функционирующие параллельно
>> с системным пакетным менагером, существуют очень давно. Вспомнить тот же autoconf/automake.
> o_O по моим сведениям использование autoconf/automake не приводит к появлению в системе
> библиотек, неизвестных пакетному менеджеру системы, сами не ведут никакого учёта установленного
> и сторого говоря пакетным менеджером не являются. во всяком случае в
> портах и портежах это далеко не так. Я не спорю, что
> при горячем желании это можно сделать, но пока я не видел
> таких решений. А вот упомянутые pip/gems/cpan - видел, и применяются они
> ровно так, как не надо.Вы видели как порты и портежи используют pip/gems/cpan? Примерно так же как и autoconf/automake. Нет, я понимаю, что вас раздражает -- я назвал autoconf/automake пакетным менагером, вы же при этом считаете, что отслеживание зависимостей, установленных файлов, конфликтов между файлами и прочие функции -- неотъемлимыми атрибутами пакетного менагера, без которых он совсем не менагер. Мы можем поспорить на этот счёт, если вы хотите, но это будет терминологический спор, исход которого никак не изменит истинности/ложности того, что было сказано мною -- в худшем случае, мне придётся подредактировать то моё сообщение и заменить там слова "пакетный менагер" на какое-то другое собирательное слово/слова, которые будут означать множество софта, включающее в себя и pip/gems и autotools.
Мне совершенно не хочется спорить о какой-то туфте типа слов. Слова -- это просто способ сотрясать воздух, спорить из-за них глупо. Давайте считать, что я проиграл спор, но при одном условии: дайте мне этот собирательный термин, который я смогу воткнуть вместо "пакетного менагера". Я отредактирую то своё сообщение, приведу его к нераздражающему вас виду, и ещё оставлю покаянный постскриптум, с пояснением внесённой правки.
> ...и с этим сложно спорить. Да, теоретически можно так и сделать. И
> если кто-то реализует - вполне возможно кому-то такое понадобится. И если
> будет работать отлично - так ещё один source-based с унифицированной системой
> сборки, она же пакетный менеджер - не останется без аудитории. Но
> пока это теоретические выкладки.
Практически, всё сведётся к тому, что появится ещё один eclass, который позволит в две строчки кода укладывать ебилды для софта использующего biicode. Может быть даже появятся скрипты, которые будут генерировать эти самые ебилды, на основании конфига проекта. Неплохо было бы, м? Держать /usr/local/portage в когерентном состоянии стало бы ещё проще.
> Степень ужасности зависит ровно от применения. Сам молоток не является ужасным, но
> если его держат за боёк и забивают рукоятью - это ужасно.
> Так что если оно будет применяться в качестве единственного менеджера пакетов
> - это нормально (хотя и бесполезно для остальных). Если подобно cpan/gems
> в портах/портежах - это выглядит ужасно. Да, и будем честными, не
> только выглядит. Это и есть ужасно.
Подробнее можно? Вас не устраивает то, что ebuild'ы для ruby-софта оказываются обёртками над gem? А когда эти ebuild'ы -- обёртки над autoconf/automake? Это тоже не нравится? Почему?
Мне кажется это замечательно -- есть куча средств сборки и установки софта, и ebuild при таком подходе становится мета-средством установки софта, которое унифицирует интерфейс, прячет различия, приводит всё к общему знаменателю. Собственно то, чем этот ebuild и являлся все эти годы, начиная с момента своего рождения.
