https://www.opennet.me/openforum/vsluhforumID3/97696.html Корнелиус Шумахер (Cornelius Schumacher), президент организации KDE e.V., сообщил (http://blog.cornelius-schumacher.de/2014/08/announcing-first-inqlude-alpha-release.html) о первом альфа-выпуске интерфейса командной строки для каталога Inqlude (http://inqlude.org/), в котором по аналогии с Ruby gems и Perl cpan подготовлен архив доступных библиотек, биндингов, модулей и расширений, ориентированных на совместное использование с Qt и KDE. В частности, для установки из Inqlude доступны 60 библиотек из состава KDE Frameworks 5 (http://www.opennet.ru/opennews/art.shtml?num=40346). Код утилиты inqlude распространяется (https://github.com/cornelius/inqlude) под лицензией GPL. <br><br><br>При помощи развиваемого сервиса, который будет включать информацию о всех доступных Qt-библиотеках, разработчики, использующие Qt, смогут быстро найти интересующую библиотеку или расширение. Утилита пока отстаёт по функциональности от Ruby Gems, но к моменту первого релиза позволит управлять локальной установкой библиотек. <br><br><br>Также буд https://www.opennet.me/openforum/vsluhforumID3/97696.html#49 Thu, 14 Aug 2014 07:28:53 GMT &gt; У каждого дистрибутива может быть свой "policy".<br><br>Да, так и есть. Как и у каждого - свой конфиг/шаблон для gem2rpm.<br><br>&gt;&gt; Значит ты с этим не сталкивался, следовательно, рассуждать тебе об этом - <br>&gt;&gt; глупо.<br>&gt; Ну да, мозгов-то нет. Думать не умею.<br><br>Чтобы о чём-то думать, надо бы хоть немножно "быть в курсе" этого "чего-то":)<br> https://www.opennet.me/openforum/vsluhforumID3/97696.html#48 Thu, 14 Aug 2014 07:20:30 GMT &gt;&gt;&gt;&gt; Нет. Я ничего не предлагал. Но если что-то предлагать, то паковать только <br>&gt;&gt;&gt;&gt; те модули, что нужны достаточно часто, чтобы добавлять их в репозитории <br>&gt;&gt;&gt;&gt; дистрибутива. А остальные, например, собирать вручную (в пару действий) и потом <br>&gt;&gt;&gt;&gt; устанавливать через тот же пакетный менеджер. Всё как и раньше с <br>&gt;&gt;&gt;&gt; обычными пакетами :).<br>&gt;&gt;&gt; man gem2rpm <br>&gt;&gt; Как он узнаёт названия пакетов для зависимостей? Разные дистрибутивы могут по-разному называть <br>&gt;&gt; один и тот же пакет. В общем, это кривокостыль, а не <br>&gt;&gt; решение, IMHO.<br>&gt; ruby-, perl-, etc.-пакеты в дистрибутивах именуются согласно policy, а не как попало. <br><br>&lt;captain&gt;<br>У каждого дистрибутива может быть свой "policy".<br>&lt;/captain&gt;<br><br>&gt;&gt;&gt; Если "гемы" для ругих языков более-менее вменяемые, то сооружение такого гем2rpm занимает <br>&gt;&gt;&gt; полчаса-час.<br>&gt;&gt; Прошу простить, но не понял. Что имелось в виду под "сооружение такого <br>&gt;&gt; гем2rpm занимает полчаса-час"?<br>&gt; Значит ты с этим не сталкивался, следовательно, рассуждать тебе об этом - <br>&gt; глупо.<br><br>Ну https://www.opennet.me/openforum/vsluhforumID3/97696.html#47 Thu, 14 Aug 2014 05:47:09 GMT &gt;&gt;&gt; Нет. Я ничего не предлагал. Но если что-то предлагать, то паковать только <br>&gt;&gt;&gt; те модули, что нужны достаточно часто, чтобы добавлять их в репозитории <br>&gt;&gt;&gt; дистрибутива. А остальные, например, собирать вручную (в пару действий) и потом <br>&gt;&gt;&gt; устанавливать через тот же пакетный менеджер. Всё как и раньше с <br>&gt;&gt;&gt; обычными пакетами :).<br>&gt;&gt; man gem2rpm <br>&gt; Как он узнаёт названия пакетов для зависимостей? Разные дистрибутивы могут по-разному называть <br>&gt; один и тот же пакет. В общем, это кривокостыль, а не <br>&gt; решение, IMHO.<br><br>ruby-, perl-, etc.-пакеты в дистрибутивах именуются согласно policy, а не как попало.<br><br>&gt;&gt; Если "гемы" для ругих языков более-менее вменяемые, то сооружение такого гем2rpm занимает <br>&gt;&gt; полчаса-час.<br>&gt; Прошу простить, но не понял. Что имелось в виду под "сооружение такого <br>&gt; гем2rpm занимает полчаса-час"?<br><br>Значит ты с этим не сталкивался, следовательно, рассуждать тебе об этом - глупо.<br> https://www.opennet.me/openforum/vsluhforumID3/97696.html#46 Thu, 14 Aug 2014 03:47:11 GMT &gt;&gt; Нет. Я ничего не предлагал. Но если что-то предлагать, то паковать только <br>&gt;&gt; те модули, что нужны достаточно часто, чтобы добавлять их в репозитории <br>&gt;&gt; дистрибутива. А остальные, например, собирать вручную (в пару действий) и потом <br>&gt;&gt; устанавливать через тот же пакетный менеджер. Всё как и раньше с <br>&gt;&gt; обычными пакетами :).<br>&gt; man gem2rpm <br><br>Как он узнаёт названия пакетов для зависимостей? Разные дистрибутивы могут по-разному называть один и тот же пакет. В общем, это кривокостыль, а не решение, IMHO.<br><br>&gt; Если "гемы" для ругих языков более-менее вменяемые, то сооружение такого гем2rpm занимает <br>&gt; полчаса-час.<br><br>Прошу простить, но не понял. Что имелось в виду под "сооружение такого гем2rpm занимает полчаса-час"?<br> https://www.opennet.me/openforum/vsluhforumID3/97696.html#45 Wed, 13 Aug 2014 05:14:08 GMT &gt; Речь шла о сравнении утилит пакетирования отдельных модулей типа dh-make-perl с нативными <br>&gt; системами управления модулями для каждого языка.<br><br>Хм, а ещё речь шла про использование более чем одного пакетного менеджера. И про вариант того, как жить на одном менеджере (и зачем). Учитывая всю нить диалога, я сравниваю использование dpkg-buildpackage + dpkg (один пакетный менеджер) против cpan-а/etc (несколько пакетных менеджеров). И первое интегрально удобнее, лично мне. Единый интерфейс управления установленными пакетами (например, если хочешь проверить хеш-суммы файлов всей системы - это удобно), единая база пакетов позволяет верно строить зависимости (без дублирования установок) и т.п.<br><br>И, повторюсь, "debian/" может и другой человек пожертвовать, и применять dh-make-perl вообще не потребуется в таком случае.<br><br>В общем, лично для меня, лучше бы всё шло классическим путём. То есть, если бы просто в результате пожертвований сообщества, работать с нужными пакетами становилось бы всё проще и проще. Чем больш https://www.opennet.me/openforum/vsluhforumID3/97696.html#44 Wed, 13 Aug 2014 04:59:34 GMT Речь шла о сравнении утилит пакетирования отдельных модулей типа dh-make-perl с нативными системами управления модулями для каждого языка. Ну а вы опять предлагаете в каждый дистр забросить несколько сотен тысяч пакетов, чтобы покрыть каждый модуль для каждого языка/либы. Круг замкнулся. <br> https://www.opennet.me/openforum/vsluhforumID3/97696.html#43 Tue, 12 Aug 2014 22:39:40 GMT &gt; Нет. Я ничего не предлагал. Но если что-то предлагать, то паковать только <br>&gt; те модули, что нужны достаточно часто, чтобы добавлять их в репозитории <br>&gt; дистрибутива. А остальные, например, собирать вручную (в пару действий) и потом <br>&gt; устанавливать через тот же пакетный менеджер. Всё как и раньше с <br>&gt; обычными пакетами :).<br><br>man gem2rpm<br><br>Если "гемы" для ругих языков более-менее вменяемые, то сооружение такого гем2rpm занимает полчаса-час.<br> https://www.opennet.me/openforum/vsluhforumID3/97696.html#42 Tue, 12 Aug 2014 20:00:46 GMT &gt;&gt;Но если что-то предлагать, то паковать только те модули, что нужны достаточно часто, чтобы добавлять их в репозитории дистрибутива. А остальные, например, собирать вручную (в пару действий) и потом устанавливать через тот же пакетный менеджер <br>&gt; Это и так уже сделано, по-крайней мере в debian для perl и <br>&gt; ruby <br>&gt; Но cpan и прочая при этом по-прежнему нужны: <br>&gt; 1. Удобней и привычней, чем через dh-make-perl/gem2deb/ruby-pkg-tools <br><br>Ну кому как. Лично мне удобнее, когда все пакеты учтены через один пакетный менеджер, а не через несколько (в результате дублируя установки).<br><br>&gt; 2. Умеют работать с зависимостями <br><br>А apt/yum/emerge/etc не имеют?<br><br>&gt; 3. Зачастую нужна установка локальная, а не общесистемная, то есть пользы от <br>&gt; пакетирования ноль.<br><br>Во-первых, пакетные менеджеры обычно поддерживают "локальную установку". Во-вторых, как это ноль? Дерево хеш-сумм, правильная работа с завивимостями (см. выше) и мн. другое.<br> https://www.opennet.me/openforum/vsluhforumID3/97696.html#41 Tue, 12 Aug 2014 18:44:47 GMT &gt;Но если что-то предлагать, то паковать только те модули, что нужны достаточно часто, чтобы добавлять их в репозитории дистрибутива. А остальные, например, собирать вручную (в пару действий) и потом устанавливать через тот же пакетный менеджер<br><br>Это и так уже сделано, по-крайней мере в debian для perl и ruby<br><br>Но cpan и прочая при этом по-прежнему нужны:<br>1. Удобней и привычней, чем через dh-make-perl/gem2deb/ruby-pkg-tools<br>2. Умеют работать с зависимостями<br>3. Зачастую нужна установка локальная, а не общесистемная, то есть пользы от пакетирования ноль. <br>