Корнелиус Шумахер (Cornelius Schumacher), президент организации KDE e.V., сообщил (http://blog.cornelius-schumacher.de/2014/08/announcing-first...) о первом альфа-выпуске интерфейса командной строки для каталога Inqlude (http://inqlude.org/), в котором по аналогии с Ruby gems и Perl cpan подготовлен архив доступных библиотек, биндингов, модулей и расширений, ориентированных на совместное использование с Qt и KDE. В частности, для установки из Inqlude доступны 60 библиотек из состава KDE Frameworks 5 (http://www.opennet.me/opennews/art.shtml?num=40346). Код утилиты inqlude распространяется (https://github.com/cornelius/inqlude) под лицензией GPL.
При помощи развиваемого сервиса, который будет включать информацию о всех доступных Qt-библиотеках, разработчики, использующие Qt, смогут быстро найти интересующую библиотеку или расширение. Утилита пока отстаёт по функциональности от Ruby Gems, но к моменту первого релиза позволит управлять локальной установкой библиотек.
Также будут предоставлены средства для интеграции с пакетными менеджерами различных дистрибутивов, что позволит производить установку библиотек с использованием штатных средств управления пакетами, даже если искомая библиотека отсутствует в репозитории дистрибутива (при помощи сервиса Open Build Service планируется сформировать бинарные сборки библиотек для всех крупных дистрибутивов Linux).URL: http://blog.cornelius-schumacher.de/2014/08/announcing-first...
Новость: http://www.opennet.me/opennews/art.shtml?num=40364
Я бы на месте разработчиков ориентировался только только на два дистрибутива debian-unstable(ubuntu) и redhat(fedora)(suse?), все остальные велосипедисты пускай педалят сами как хотят.
ага, и пишут проги сами и с нуля. Не, не пойдёт, не честно.
ты не у портеринга учился? не ? а то тот тоже заявлял что портируемость GNOME не нужна - достаточно поддерживать только RedHat и его клоны..
как думаешь каким разработкам больший респект, которые только рассчитаны на определенные дистры или любые?
Как думаешь, какое дело разработчику до респектов пользователей, которые не платят?
Респекты за оплату?
>Я бы на месте разработчиковДа ты уже разработчик! Делай давай :-D
...и раздавал только бинарные пакеты.Ты не одинок, к сожалению.
Но если речь идёт об опенсорсе, разработчик должен выкатывать *.tgz(tar.gz, tar.bz2 и тыды). А остальные компилят, заворачивают в пакеты, пишут ебилды и прочее. Повторюсь, это если речь об опенсорсе. Если о проприетарщине - да. Собрали под бубунту и расслабились. Ах нет, rpm ещё. Ну теперь точно расслабились.
не путь кросплатформенного фреймворка.
>Я бы на месте разработчиков ориентировался только только на два дистрибутива debian-unstable(ubuntu) и redhat(fedora)(suse?), все остальные велосипедисты пускай педалят сами как хотят.Равно как и разработчики любых дистрибутивов могли бы ориентироваться на xfce4/lxde/что_там_ещё, а KDE оказалось бы в пролёте. К счастью, многие разработчики читали басню про свинью под дубом или что-то похожее, слышали, что бывает, если пилить сук на котором сидишь, да вообще умеют подмечать причинно-следственные связи. Если, конечно, это не разработчики Gnome 3.
Когда уже сделают пакетные менеджеры для пакетных менеджеров?
Жду-не-дождусь куайнов типа:
apt-get install $(yum install $(gem install $(npm install $(go get $(composer install $(...))))))
emerge -av app-arch/rpm app-arch/dpkg не подойдет?
> Когда уже сделают пакетные менеджеры для пакетных менеджеров?PackageKit.
А чем оно похоже на RubyGems-то?
> А чем оно похоже на RubyGems-то?Ещё один "Скачай, быстро! без SMS!!, с инета себе в хоум кучу %^&та. Каждый день новую! Не жди1, всё равно сломается.".
ни дня без кривого лисопета.пришло пора переустанавливать линукс, линукс сам не переустановится
gem install kde?неужели будут такие же проблемы с зависимостями, как в рубленом геморрое?
Децентрализация управления пакетами выглядит по идиотски, вантуз-вэй какой-то.
Ну так блин, рубисты - макофаги, у них нормальных репок можно считать что нет. Вот и велосипедят в обход нормального пакетного менеджера. Фагготы!!!
> Фагготы!!!При чём здесь английское мясное блюдо?
> При чём здесь английское мясное блюдо?Салат мясной "ошибка сапера"? :)
А мне нравится вантуз-вей и я бы с удовольствием использовал бы дистро с такими идеями управления программами.
Так вантуз и используй.
Он не свободный и не такой гибкий.
> Он не свободный и не такой гибкий.Так нафига тебе свободная и гибкая система, если все-равно вантуз в итоге хочется?
> Он не свободный и не такой гибкий.Для того, чтобы свободно нагибаться тебе гибкости хватит.
Да блин, зае...! Отобрать по дефолту права на запись в хомяка вообще, чтоб эти велосипедисты картон жрали.
> Отобрать по дефолту права на запись в хомяка вообще, чтоб эти велосипедисты картон жрали.s/запись в/запуск из/
Всех убью, один останусь, бота кикну и забанюсь!
> Всех убью, один останусь, бота кикну и забанюсь!Chanserv с массовыми расстрелами справляется намного лучше. Проверено.
Не люблю я все эти gem-ы, npm-ы, pear-ы и inqlude-ы. Сама идея использования в одной системе более чем одного пакетного менеджера вызывает отвращение.
<captain>
Однако никто не мешает подготавливать нужные пакеты для своего основного пакетного менеджера и тупо не пользоваться этими inqlude-ами. Но, к сожалению, необходимость включения нужных пакетов в репозитории снизится (из-за наличия простого альтернативного пути) и, к тому же, будут появляться куча howto-шек с использованием inqlude вместо apt-get/emerge/yum/etc.
</captain>
> использования в одной системе более чем одного пакетного менеджера вызывает отвращение.Потому что виндyзятничество в чистом виде. И забота о виндyзятниках, у которых в системе нормального пакетного менеджера нет.
>> использования в одной системе более чем одного пакетного менеджера вызывает отвращение.
> Потому что виндyзятничество
>у которых в системе нормального пакетного менеджера нет.Аноним, 18:10 , 11-Авг-14, (14) +1 !*!
>Ну так блин, рубисты - макофаги, у них нормальных репок можно считатьНимус, 15:26 , 11-Авг-14, (1) –25
>ориентировался только только на два дистрибутива debian-unstable(ubuntu) и redhatМилая сказка про белого бычка. $тут_ссылка_на_xkcd.jpg
> Не люблю я все эти gem-ы, npm-ы, pear-ы и inqlude-ы. Сама идея
> использования в одной системе более чем одного пакетного менеджера вызывает отвращение.The Comprehensive Perl Archive Network (CPAN) currently has 136,959 Perl modules in 30,106 distributions
Предлагаешь для каждого модуля сделать отдельный пакет в дистре? А потом аналогичное для gems/pear/итд. И все это на фоне того, что сейчас в дистрах от 12к до 30к пакетов.
>> Не люблю я все эти gem-ы, npm-ы, pear-ы и inqlude-ы. Сама идея
>> использования в одной системе более чем одного пакетного менеджера вызывает отвращение.
> The Comprehensive Perl Archive Network (CPAN) currently has 136,959 Perl modules in
> 30,106 distributions
> Предлагаешь для каждого модуля сделать отдельный пакет в дистре?Нет. Я ничего не предлагал. Но если что-то предлагать, то паковать только те модули, что нужны достаточно часто, чтобы добавлять их в репозитории дистрибутива. А остальные, например, собирать вручную (в пару действий) и потом устанавливать через тот же пакетный менеджер. Всё как и раньше с обычными пакетами :).
Вот другие пакеты, которые более ли менее используются, начинают обрастать потихоньку всякими директориями вроде "debian", что делает сборку вручную тривиальной задачей... и ускоряет процесс перемещения в стандартные репозитории всяких дистрибутивов. Это естественный процесс, который работает давно и лично меня устраивает.
> А потом аналогичное для gems/pear/итд.
Ну да, почему нет?
> И все это на фоне того, что сейчас в дистрах от 12к до 30к пакетов.
Да, я знаю, что не хватает рабочей силы, чтобы сопровождать всё по-хорошему. И?
Я давно с этим смирился и хорошо понимаю (как мне кажется) почему появляются все эти inqlude-ы.
>Но если что-то предлагать, то паковать только те модули, что нужны достаточно часто, чтобы добавлять их в репозитории дистрибутива. А остальные, например, собирать вручную (в пару действий) и потом устанавливать через тот же пакетный менеджерЭто и так уже сделано, по-крайней мере в debian для perl и ruby
Но cpan и прочая при этом по-прежнему нужны:
1. Удобней и привычней, чем через dh-make-perl/gem2deb/ruby-pkg-tools
2. Умеют работать с зависимостями
3. Зачастую нужна установка локальная, а не общесистемная, то есть пользы от пакетирования ноль.
>>Но если что-то предлагать, то паковать только те модули, что нужны достаточно часто, чтобы добавлять их в репозитории дистрибутива. А остальные, например, собирать вручную (в пару действий) и потом устанавливать через тот же пакетный менеджер
> Это и так уже сделано, по-крайней мере в debian для perl и
> ruby
> Но cpan и прочая при этом по-прежнему нужны:
> 1. Удобней и привычней, чем через dh-make-perl/gem2deb/ruby-pkg-toolsНу кому как. Лично мне удобнее, когда все пакеты учтены через один пакетный менеджер, а не через несколько (в результате дублируя установки).
> 2. Умеют работать с зависимостями
А apt/yum/emerge/etc не имеют?
> 3. Зачастую нужна установка локальная, а не общесистемная, то есть пользы от
> пакетирования ноль.Во-первых, пакетные менеджеры обычно поддерживают "локальную установку". Во-вторых, как это ноль? Дерево хеш-сумм, правильная работа с завивимостями (см. выше) и мн. другое.
Речь шла о сравнении утилит пакетирования отдельных модулей типа dh-make-perl с нативными системами управления модулями для каждого языка. Ну а вы опять предлагаете в каждый дистр забросить несколько сотен тысяч пакетов, чтобы покрыть каждый модуль для каждого языка/либы. Круг замкнулся.
> Речь шла о сравнении утилит пакетирования отдельных модулей типа dh-make-perl с нативными
> системами управления модулями для каждого языка.Хм, а ещё речь шла про использование более чем одного пакетного менеджера. И про вариант того, как жить на одном менеджере (и зачем). Учитывая всю нить диалога, я сравниваю использование dpkg-buildpackage + dpkg (один пакетный менеджер) против cpan-а/etc (несколько пакетных менеджеров). И первое интегрально удобнее, лично мне. Единый интерфейс управления установленными пакетами (например, если хочешь проверить хеш-суммы файлов всей системы - это удобно), единая база пакетов позволяет верно строить зависимости (без дублирования установок) и т.п.
И, повторюсь, "debian/" может и другой человек пожертвовать, и применять dh-make-perl вообще не потребуется в таком случае.
В общем, лично для меня, лучше бы всё шло классическим путём. То есть, если бы просто в результате пожертвований сообщества, работать с нужными пакетами становилось бы всё проще и проще. Чем больше используется пакет, тем более полно он обрастает удобными "фишками", вроде того же "debian/" или уже готовыми пакетами или ещё чем.
Однако я не спорю против всякие pear-ы с inqlude-ами. Просто я считаю это костылём из-за лени людей делать что-то правильно. Однако костыль по-своему оправданный.
> Ну а вы опять предлагаете
> в каждый дистр забросить несколько сотен тысяч пакетов, чтобы покрыть каждый
> модуль для каждого языка/либы.Ложь.
> Нет. Я ничего не предлагал. Но если что-то предлагать, то паковать только
> те модули, что нужны достаточно часто, чтобы добавлять их в репозитории
> дистрибутива. А остальные, например, собирать вручную (в пару действий) и потом
> устанавливать через тот же пакетный менеджер. Всё как и раньше с
> обычными пакетами :).man gem2rpm
Если "гемы" для ругих языков более-менее вменяемые, то сооружение такого гем2rpm занимает полчаса-час.
>> Нет. Я ничего не предлагал. Но если что-то предлагать, то паковать только
>> те модули, что нужны достаточно часто, чтобы добавлять их в репозитории
>> дистрибутива. А остальные, например, собирать вручную (в пару действий) и потом
>> устанавливать через тот же пакетный менеджер. Всё как и раньше с
>> обычными пакетами :).
> man gem2rpmКак он узнаёт названия пакетов для зависимостей? Разные дистрибутивы могут по-разному называть один и тот же пакет. В общем, это кривокостыль, а не решение, IMHO.
> Если "гемы" для ругих языков более-менее вменяемые, то сооружение такого гем2rpm занимает
> полчаса-час.Прошу простить, но не понял. Что имелось в виду под "сооружение такого гем2rpm занимает полчаса-час"?
>>> Нет. Я ничего не предлагал. Но если что-то предлагать, то паковать только
>>> те модули, что нужны достаточно часто, чтобы добавлять их в репозитории
>>> дистрибутива. А остальные, например, собирать вручную (в пару действий) и потом
>>> устанавливать через тот же пакетный менеджер. Всё как и раньше с
>>> обычными пакетами :).
>> man gem2rpm
> Как он узнаёт названия пакетов для зависимостей? Разные дистрибутивы могут по-разному называть
> один и тот же пакет. В общем, это кривокостыль, а не
> решение, IMHO.ruby-, perl-, etc.-пакеты в дистрибутивах именуются согласно policy, а не как попало.
>> Если "гемы" для ругих языков более-менее вменяемые, то сооружение такого гем2rpm занимает
>> полчаса-час.
> Прошу простить, но не понял. Что имелось в виду под "сооружение такого
> гем2rpm занимает полчаса-час"?Значит ты с этим не сталкивался, следовательно, рассуждать тебе об этом - глупо.
>>>> Нет. Я ничего не предлагал. Но если что-то предлагать, то паковать только
>>>> те модули, что нужны достаточно часто, чтобы добавлять их в репозитории
>>>> дистрибутива. А остальные, например, собирать вручную (в пару действий) и потом
>>>> устанавливать через тот же пакетный менеджер. Всё как и раньше с
>>>> обычными пакетами :).
>>> man gem2rpm
>> Как он узнаёт названия пакетов для зависимостей? Разные дистрибутивы могут по-разному называть
>> один и тот же пакет. В общем, это кривокостыль, а не
>> решение, IMHO.
> ruby-, perl-, etc.-пакеты в дистрибутивах именуются согласно policy, а не как попало.<captain>
У каждого дистрибутива может быть свой "policy".
</captain>>>> Если "гемы" для ругих языков более-менее вменяемые, то сооружение такого гем2rpm занимает
>>> полчаса-час.
>> Прошу простить, но не понял. Что имелось в виду под "сооружение такого
>> гем2rpm занимает полчаса-час"?
> Значит ты с этим не сталкивался, следовательно, рассуждать тебе об этом -
> глупо.Ну да, мозгов-то нет. Думать не умею.
> У каждого дистрибутива может быть свой "policy".Да, так и есть. Как и у каждого - свой конфиг/шаблон для gem2rpm.
>> Значит ты с этим не сталкивался, следовательно, рассуждать тебе об этом -
>> глупо.
> Ну да, мозгов-то нет. Думать не умею.Чтобы о чём-то думать, надо бы хоть немножно "быть в курсе" этого "чего-то":)
> Не люблю я все эти gem-ы, npm-ы, pear-ы и inqlude-ы. Сама идея
> использования в одной системе более чем одного пакетного менеджера вызывает отвращение.Вот http://www.mancoosi.org/ люди пытаются _мержить_ пакедж манагеры. Или типа того.
> <captain>
> Однако никто не мешает подготавливать нужные пакеты для своего основного пакетного менеджера