The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Проект KDE выпустил альфа-версию утилиты inqlude, аналога Ruby Gems

11.08.2014 15:14

Корнелиус Шумахер (Cornelius Schumacher), президент организации KDE e.V., сообщил о первом альфа-выпуске интерфейса командной строки для каталога Inqlude, в котором по аналогии с Ruby gems и Perl cpan подготовлен архив доступных библиотек, биндингов, модулей и расширений, ориентированных на совместное использование с Qt и KDE. В частности, для установки из Inqlude доступны 60 библиотек из состава KDE Frameworks 5. Код утилиты inqlude распространяется под лицензией GPL.

При помощи развиваемого сервиса, который будет включать информацию о всех доступных Qt-библиотеках, разработчики, использующие Qt, смогут быстро найти интересующую библиотеку или расширение. Утилита пока отстаёт по функциональности от Ruby Gems, но к моменту первого релиза позволит управлять локальной установкой библиотек.

Также будут предоставлены средства для интеграции с пакетными менеджерами различных дистрибутивов, что позволит производить установку библиотек с использованием штатных средств управления пакетами, даже если искомая библиотека отсутствует в репозитории дистрибутива (при помощи сервиса Open Build Service планируется сформировать бинарные сборки библиотек для всех крупных дистрибутивов Linux).

  1. Главная ссылка к новости (http://blog.cornelius-schumach...)
  2. OpenNews: Выпуск KDE Frameworks 5.1
  3. OpenNews: Представлен InQlude, архив библиотек для Qt, похожий на CPAN и RubyGems
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/40364-kde
Ключевые слова: kde, inqlude
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (45) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Нимус (?), 15:26, 11/08/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –29 +/
    Я бы на месте разработчиков ориентировался только только на два дистрибутива debian-unstable(ubuntu) и redhat(fedora)(suse?), все остальные велосипедисты пускай педалят сами как хотят.
     
     
  • 2.2, Аноним (2), 15:31, 11/08/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    ага, и пишут проги сами и с нуля. Не, не пойдёт, не честно.
     
  • 2.5, анонимный (?), 15:49, 11/08/2014 [^] [^^] [^^^] [ответить]  
  • +8 +/
    ты не у портеринга учился? не ? а то тот тоже заявлял что портируемость GNOME не нужна - достаточно поддерживать только RedHat и его клоны..
     
  • 2.8, qqq (??), 16:50, 11/08/2014 [^] [^^] [^^^] [ответить]  
  • +/
    как думаешь каким разработкам больший респект, которые только рассчитаны на определенные дистры или любые?
     
     
  • 3.10, sage (??), 17:03, 11/08/2014 [^] [^^] [^^^] [ответить]  
  • –6 +/
    Как думаешь, какое дело разработчику до респектов пользователей, которые не платят?
     
     
  • 4.20, qqq (??), 20:17, 11/08/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Респекты за оплату?
     
  • 2.9, chinarulezzz (ok), 16:51, 11/08/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Я бы на месте разработчиков

    Да ты уже разработчик! Делай давай :-D

     
  • 2.25, Куяврег (?), 00:38, 12/08/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ...и раздавал только бинарные пакеты.

    Ты не одинок, к сожалению.

    Но если речь идёт об опенсорсе, разработчик должен выкатывать *.tgz(tar.gz, tar.bz2 и тыды). А остальные компилят, заворачивают в пакеты, пишут ебилды и прочее.  Повторюсь, это если речь об опенсорсе. Если о проприетарщине - да. Собрали под бубунту и расслабились. Ах нет, rpm ещё. Ну теперь точно расслабились.

     
  • 2.26, Кевин (?), 01:01, 12/08/2014 [^] [^^] [^^^] [ответить]  
  • +/
    не путь кросплатформенного фреймворка.
     
  • 2.40, AlexYeCu_not_logged (?), 17:15, 12/08/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >Я бы на месте разработчиков ориентировался только только на два дистрибутива debian-unstable(ubuntu) и redhat(fedora)(suse?), все остальные велосипедисты пускай педалят сами как хотят.

    Равно как и разработчики любых дистрибутивов могли бы ориентироваться на xfce4/lxde/что_там_ещё, а KDE оказалось бы в пролёте. К счастью, многие разработчики читали басню про свинью под дубом или что-то похожее, слышали, что бывает, если пилить сук на котором сидишь, да вообще умеют подмечать причинно-следственные связи. Если, конечно, это не разработчики Gnome 3.

     

  • 1.3, Аноним (-), 15:32, 11/08/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Когда уже сделают пакетные менеджеры для пакетных менеджеров?
     
     
  • 2.4, Аноним (-), 15:45, 11/08/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Жду-не-дождусь куайнов типа:
    apt-get install $(yum install $(gem install $(npm install $(go get $(composer install $(...))))))
     
  • 2.15, Аноним (-), 18:24, 11/08/2014 [^] [^^] [^^^] [ответить]  
  • +/
    emerge -av app-arch/rpm app-arch/dpkg не подойдет?
     
  • 2.21, anonymous (??), 21:42, 11/08/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Когда уже сделают пакетные менеджеры для пакетных менеджеров?

    PackageKit.

     

  • 1.6, Аноним (-), 16:04, 11/08/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А чем оно похоже на RubyGems-то?
     
     
  • 2.7, Andrey Mitrofanov (?), 16:43, 11/08/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > А чем оно похоже на RubyGems-то?

    Ещё один "Скачай, быстро! без SMS!!, с инета себе в хоум кучу %^&та. Каждый день новую! Не жди1, всё равно сломается.".

     

  • 1.11, Аноним (-), 17:44, 11/08/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    ни дня без кривого лисопета.

    пришло пора переустанавливать линукс, линукс сам не переустановится

     
  • 1.12, Журналовращатель (?), 17:47, 11/08/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    gem install kde?

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

    Децентрализация управления пакетами выглядит по идиотски, вантуз-вэй какой-то.

     
     
  • 2.14, Аноним (-), 18:10, 11/08/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну так блин, рубисты - макофаги, у них нормальных репок можно считать что нет. Вот и велосипедят в обход нормального пакетного менеджера. Фагготы!!!
     
     
  • 3.22, anonymous (??), 21:44, 11/08/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >  Фагготы!!!

    При чём здесь английское мясное блюдо?

     
     
  • 4.30, Аноним (-), 08:52, 12/08/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > При чём здесь английское мясное блюдо?

    Салат мясной "ошибка сапера"? :)

     
  • 2.16, Никто (??), 19:00, 11/08/2014 [^] [^^] [^^^] [ответить]  
  • –4 +/
    А мне нравится вантуз-вей и я бы с удовольствием использовал бы дистро с такими идеями управления программами.
     
     
  • 3.17, Аноним (-), 19:20, 11/08/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Так вантуз и используй.
     
     
  • 4.18, Тфь (?), 19:25, 11/08/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Он не свободный и не такой гибкий.
     
     
  • 5.19, Аноним (-), 19:55, 11/08/2014 [^] [^^] [^^^] [ответить]  
  • +6 +/
    > Он не свободный и не такой гибкий.

    Так нафига тебе свободная и гибкая система, если все-равно вантуз в итоге хочется?

     
  • 5.23, Аноним (-), 22:14, 11/08/2014 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Он не свободный и не такой гибкий.

    Для того, чтобы свободно нагибаться тебе гибкости хватит.

     

  • 1.13, Аноним (-), 18:08, 11/08/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Да блин, зае...! Отобрать по дефолту права на запись в хомяка вообще, чтоб эти велосипедисты картон жрали.
     
     
  • 2.24, Аноним (-), 22:15, 11/08/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Отобрать по дефолту права на запись в хомяка вообще, чтоб эти велосипедисты картон жрали.

    s/запись в/запуск из/

     
     
  • 3.27, Аноним (-), 02:16, 12/08/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Всех убью, один останусь, бота кикну и забанюсь!
     
     
  • 4.31, Аноним (-), 08:54, 12/08/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Всех убью, один останусь, бота кикну и забанюсь!

    Chanserv с массовыми расстрелами справляется намного лучше. Проверено.

     

  • 1.28, Xaionaro (ok), 08:16, 12/08/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Не люблю я все эти gem-ы, npm-ы, pear-ы и inqlude-ы. Сама идея использования в одной системе более чем одного пакетного менеджера вызывает отвращение.
    <captain>
    Однако никто не мешает подготавливать нужные пакеты для своего основного пакетного менеджера и тупо не пользоваться этими inqlude-ами. Но, к сожалению, необходимость включения нужных пакетов в репозитории снизится (из-за наличия простого альтернативного пути) и, к тому же, будут появляться куча howto-шек с использованием inqlude вместо apt-get/emerge/yum/etc.
    </captain>
     
     
  • 2.29, Аноним (-), 08:51, 12/08/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > использования в одной системе более чем одного пакетного менеджера вызывает отвращение.

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

     
     
  • 3.33, Andrey Mitrofanov (?), 09:32, 12/08/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> использования в одной системе более чем одного пакетного менеджера вызывает отвращение.
    > Потому что виндyзятничество
    >у которых в системе нормального пакетного менеджера нет.

    Аноним, 18:10 , 11-Авг-14, (14) +1  !*!
    >Ну так блин, рубисты - макофаги, у них нормальных репок можно считать

    Нимус, 15:26 , 11-Авг-14, (1) –25  
    >ориентировался только только на два дистрибутива debian-unstable(ubuntu) и redhat

    Милая сказка про белого бычка. $тут_ссылка_на_xkcd.jpg

     
  • 2.32, angra (ok), 09:09, 12/08/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Не люблю я все эти gem-ы, npm-ы, pear-ы и inqlude-ы. Сама идея
    > использования в одной системе более чем одного пакетного менеджера вызывает отвращение.

    The Comprehensive Perl Archive Network (CPAN) currently has 136,959 Perl modules in 30,106 distributions

    Предлагаешь для каждого модуля сделать отдельный пакет в дистре? А потом аналогичное для gems/pear/итд. И все это на фоне того, что сейчас в дистрах от 12к до 30к пакетов.  

     
     
  • 3.34, Xaionaro (ok), 11:07, 12/08/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> Не люблю я все эти 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-ы.

     
     
  • 4.41, angra (ok), 22:44, 12/08/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >Но если что-то предлагать, то паковать только те модули, что нужны достаточно часто, чтобы добавлять их в репозитории дистрибутива. А остальные, например, собирать вручную (в пару действий) и потом устанавливать через тот же пакетный менеджер

    Это и так уже сделано, по-крайней мере в debian для perl и ruby

    Но cpan и прочая при этом по-прежнему нужны:
    1. Удобней и привычней, чем через dh-make-perl/gem2deb/ruby-pkg-tools
    2. Умеют работать с зависимостями
    3. Зачастую нужна установка локальная, а не общесистемная, то есть пользы от пакетирования ноль.

     
     
  • 5.42, Xaionaro (ok), 00:00, 13/08/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >>Но если что-то предлагать, то паковать только те модули, что нужны достаточно часто, чтобы добавлять их в репозитории дистрибутива. А остальные, например, собирать вручную (в пару действий) и потом устанавливать через тот же пакетный менеджер
    > Это и так уже сделано, по-крайней мере в debian для perl и
    > ruby
    > Но cpan и прочая при этом по-прежнему нужны:
    > 1. Удобней и привычней, чем через dh-make-perl/gem2deb/ruby-pkg-tools

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

    > 2. Умеют работать с зависимостями

    А apt/yum/emerge/etc не имеют?

    > 3. Зачастую нужна установка локальная, а не общесистемная, то есть пользы от
    > пакетирования ноль.

    Во-первых, пакетные менеджеры обычно поддерживают "локальную установку". Во-вторых, как это ноль? Дерево хеш-сумм, правильная работа с завивимостями (см. выше) и мн. другое.

     
     
  • 6.44, angra (ok), 08:59, 13/08/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Речь шла о сравнении утилит пакетирования отдельных модулей типа dh-make-perl с нативными системами управления модулями для каждого языка. Ну а вы опять предлагаете в каждый дистр забросить несколько сотен тысяч пакетов, чтобы покрыть каждый модуль для каждого языка/либы. Круг замкнулся.
     
     
  • 7.45, Xaionaro (ok), 09:14, 13/08/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Речь шла о сравнении утилит пакетирования отдельных модулей типа dh-make-perl с нативными
    > системами управления модулями для каждого языка.

    Хм, а ещё речь шла про использование более чем одного пакетного менеджера. И про вариант того, как жить на одном менеджере (и зачем). Учитывая всю нить диалога, я сравниваю использование dpkg-buildpackage + dpkg (один пакетный менеджер) против cpan-а/etc (несколько пакетных менеджеров). И первое интегрально удобнее, лично мне. Единый интерфейс управления установленными пакетами (например, если хочешь проверить хеш-суммы файлов всей системы - это удобно), единая база пакетов позволяет верно строить зависимости (без дублирования установок) и т.п.

    И, повторюсь, "debian/" может и другой человек пожертвовать, и применять dh-make-perl вообще не потребуется в таком случае.

    В общем, лично для меня, лучше бы всё шло классическим путём. То есть, если бы просто в результате пожертвований сообщества, работать с нужными пакетами становилось бы всё проще и проще. Чем больше используется пакет, тем более полно он обрастает удобными "фишками", вроде того же "debian/" или уже готовыми пакетами или ещё чем.

    Однако я не спорю против всякие pear-ы с inqlude-ами. Просто я считаю это костылём из-за лени людей делать что-то правильно. Однако костыль по-своему оправданный.

    > Ну а вы опять предлагаете
    > в каждый дистр забросить несколько сотен тысяч пакетов, чтобы покрыть каждый
    > модуль для каждого языка/либы.

    Ложь.

     
  • 4.43, Led (ok), 02:39, 13/08/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Нет. Я ничего не предлагал. Но если что-то предлагать, то паковать только
    > те модули, что нужны достаточно часто, чтобы добавлять их в репозитории
    > дистрибутива. А остальные, например, собирать вручную (в пару действий) и потом
    > устанавливать через тот же пакетный менеджер. Всё как и раньше с
    > обычными пакетами :).

    man gem2rpm

    Если "гемы" для ругих языков более-менее вменяемые, то сооружение такого гем2rpm занимает полчаса-час.

     
     
  • 5.46, Xaionaro (ok), 07:47, 14/08/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> Нет. Я ничего не предлагал. Но если что-то предлагать, то паковать только
    >> те модули, что нужны достаточно часто, чтобы добавлять их в репозитории
    >> дистрибутива. А остальные, например, собирать вручную (в пару действий) и потом
    >> устанавливать через тот же пакетный менеджер. Всё как и раньше с
    >> обычными пакетами :).
    > man gem2rpm

    Как он узнаёт названия пакетов для зависимостей? Разные дистрибутивы могут по-разному называть один и тот же пакет. В общем, это кривокостыль, а не решение, IMHO.

    > Если "гемы" для ругих языков более-менее вменяемые, то сооружение такого гем2rpm занимает
    > полчаса-час.

    Прошу простить, но не понял. Что имелось в виду под "сооружение такого гем2rpm занимает полчаса-час"?

     
     
  • 6.47, Led (ok), 09:47, 14/08/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >>> Нет. Я ничего не предлагал. Но если что-то предлагать, то паковать только
    >>> те модули, что нужны достаточно часто, чтобы добавлять их в репозитории
    >>> дистрибутива. А остальные, например, собирать вручную (в пару действий) и потом
    >>> устанавливать через тот же пакетный менеджер. Всё как и раньше с
    >>> обычными пакетами :).
    >> man gem2rpm
    > Как он узнаёт названия пакетов для зависимостей? Разные дистрибутивы могут по-разному называть
    > один и тот же пакет. В общем, это кривокостыль, а не
    > решение, IMHO.

    ruby-, perl-, etc.-пакеты в дистрибутивах именуются согласно policy, а не как попало.

    >> Если "гемы" для ругих языков более-менее вменяемые, то сооружение такого гем2rpm занимает
    >> полчаса-час.
    > Прошу простить, но не понял. Что имелось в виду под "сооружение такого
    > гем2rpm занимает полчаса-час"?

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

     
     
  • 7.48, Xaionaro (ok), 11:20, 14/08/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >>>> Нет. Я ничего не предлагал. Но если что-то предлагать, то паковать только
    >>>> те модули, что нужны достаточно часто, чтобы добавлять их в репозитории
    >>>> дистрибутива. А остальные, например, собирать вручную (в пару действий) и потом
    >>>> устанавливать через тот же пакетный менеджер. Всё как и раньше с
    >>>> обычными пакетами :).
    >>> man gem2rpm
    >> Как он узнаёт названия пакетов для зависимостей? Разные дистрибутивы могут по-разному называть
    >> один и тот же пакет. В общем, это кривокостыль, а не
    >> решение, IMHO.
    > ruby-, perl-, etc.-пакеты в дистрибутивах именуются согласно policy, а не как попало.

    <captain>
    У каждого дистрибутива может быть свой "policy".
    </captain>

    >>> Если "гемы" для ругих языков более-менее вменяемые, то сооружение такого гем2rpm занимает
    >>> полчаса-час.
    >> Прошу простить, но не понял. Что имелось в виду под "сооружение такого
    >> гем2rpm занимает полчаса-час"?
    > Значит ты с этим не сталкивался, следовательно, рассуждать тебе об этом -
    > глупо.

    Ну да, мозгов-то нет. Думать не умею.

     
     
  • 8.49, Led (ok), 11:28, 14/08/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Да, так и есть Как и у каждого - свой конфиг шаблон для gem2rpm Чтобы о чём-то... текст свёрнут, показать
     
  • 2.35, Andrey Mitrofanov (?), 12:22, 12/08/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Не люблю я все эти gem-ы, npm-ы, pear-ы и inqlude-ы. Сама идея
    > использования в одной системе более чем одного пакетного менеджера вызывает отвращение.

    Вот http://www.mancoosi.org/ люди пытаются _мержить_ пакедж манагеры. Или типа того.

    > <captain>
    > Однако никто не мешает подготавливать нужные пакеты для своего основного пакетного менеджера

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру