Компания ROSA представила (http://www.rosalab.ru/blogs/urpm-tools-20-obnovlenie-utilit-...) релиз инструментария Urpm-tools 2.0 (http://wiki.rosalab.ru/index.php/Urpm-tools), расширяющего и дополняющего функциональность пакетного менеджера urpmi (http://wiki.mandriva.com/en/Tools/urpmi), используемого в дистрибутиве Mandriva Linux. По своим возможностям Urpm-tools очень близок к yum-utils, названия утилит и опции также схожи с yum-utils. Код проекта написан на языке Python и распространяется под лицензией GPLv2. Пакет с исходными текстами urpm-tools можно загрузить (ftp://ftp.free.fr/mirrors/ftp.mandriva.com/MandrivaLinux/dev.../) из стандартных репозиториев Mandriva Linux.
По сравнению с прошлым выпуском (http://www.opennet.me/opennews/art.shtml?num=32692), кроме доработки существующих утилит, представлено два новых инструмента:
- urpm-reposync - утилита для синхронизации локального набора пакетов с репозиторием дистрибутива. При синхронизации c использованием urpm-reposync, версии уже установленных в системе пакетов будут приведены в соответствие со стандартными репозиториями (например, будут удалены вручную установленные пакеты или пакеты установленные в принудительном режиме без учёта зависимостей "rpm --nodeps").- urpm-repograph - утилита для построения наглядного графа зависимостей пакетов в репозитории. Граф может быть построен как для всего репозитория, так и для отдельных пакетов.
<center><a href="http://www.rosalab.ru/system/images/17/medium/texlive_deps.p... src="http://www.opennet.me/opennews/pics_base/0_1331022275.png" style="border-style: solid; border-color: #606060; border-width: 1px;" title="" border=0></a></center>
Из изменений в существующих утилитах отмечается: обеспечение возможности удаления устаревших пакетов в анализаторе набора RPM-файлов urpm-repomanage; в urpm-downloader добавлена возможность загружать и устанавливать пакеты с debug-информацией с учётом всех зависимостей; в утилите проверки замкнутости репозитория urpm-repoclosure добавлена поддержка игнорирования указанных пользователем зависимостей; улучшена поддержка использования всех утилит в автоматических скриптах за счёт добавления дополнительных кодов возврата.URL: http://www.rosalab.ru/blogs/urpm-tools-20-obnovlenie-utilit-...
Новость: http://www.opennet.me/opennews/art.shtml?num=33279
> распространяется под лицензией GPLv2не совсем верно·
из шести файлов, содержащих copyright rosalab, пять содержат строку "either version 2 of the Licenses, or (at your option) any later version", один — без всякой привязки к версии:
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation.т.е., вполне можно расценивать, что _свою_ работу rosalab распространяет под лицензиями "gplv2 or later" и "gplv3 or later"·
>утилита для построения наглядного графа зависимостей пакетовДжва года!
Нет, правда, я о подобной штуке мечтал, но не слышал до этой новости, чтобы её кто-то реализовал. В очередной раз радуюсь, что пользуюсь Mandriva.
К слову в apt это реализовано очень давно:
apt-cache dotty
apt-cache xvcg
К сожалению, APT работает слишком быстро, и потребляет слишком мало памяти, и поэтому неприемлем для мандривы, федоры и суси.
>> утилита для построения наглядного графа зависимостей пакетов
> [...] не слышал до этой новости, чтобы её кто-то реализовал.
> В очередной раз радуюсь, что пользуюсь Mandriva.В очередной раз радуюсь, что пользуюсь аптом. :) В альте, правда, пиару меньше по поводу каждого чиха -- как и в дебиане.
А как, кстати, в Альте BuildRequires для пакета ставятся? Что выступает в качестве аналога urpmi --buildrequires [спек | SRPM]?
> А как, кстати, в Альте BuildRequires для пакета ставятся? Что выступает в
> качестве аналога urpmi --buildrequires [спек | SRPM]?предполагаю, то же самое, что и в debian:
$ apt-cache showsrc rpm | grep -i depends
Build-Depends: debhelper (>= 7.0.50), libtool, autoconf, automake, autotools-dev, autopoint, zlib1g-dev, libbz2-dev, dpkg-dev (>= 1.9.0), libpopt-dev (>= 1.6.4), libxml2-dev, libreadline-dev, libselinux1-dev [!kfreebsd-i386 !kfreebsd-amd64 !hurd-i386], libsepol1-dev [!kfreebsd-i386 !kfreebsd-amd64 !hurd-i386], libsqlite3-dev, python-support (>= 0.5.3), python-all-dev (>= 2.6), bzip2, pkg-config, libnspr4-dev, libnss3-dev, liblzma-dev, xz-utils, libmagic-dev, libelf-dev, libdw-dev, libdb-dev, liblua5.1-0-dev (>= 5.1.4-4)
> А как, кстати, в Альте BuildRequires для пакета ставятся? Что выступает в
> качестве аналога urpmi --buildrequires [спек | SRPM]?пардон, плохо выспался·
подумал, что вопрос про «как посмотреть», а на самом деле вопрос про то, как установить зависимости, необходимые для сборки·в debian такого аналога нет·
если я даю команду собрать пакет (например, через «обёртку» apt-src), зависимости будут установлены в процессе выполнения команды (будет запрошено повышение уровня привилигий, естественно)·
>> А как, кстати, в Альте BuildRequires для пакета ставятся? Что выступает в
>> качестве аналога urpmi --buildrequires [спек | SRPM]?
> в debian такого аналога нет·
> если я даю команду собрать пакет (например, через «обёртку» apt-src), зависимости
> будут установлены в процессе выполнения команды (будет запрошено повышение уровня привилигий,
> естественно)·Если я правильно помню, то именно _сборочные_ зависимости там тоже проставляются в каком-то из файлов. Дело в том, что то, что в RPM называется spec-файлом, в Debian разбросано по нескольким файлам.
> в debian такого аналога нетНу да, ну да. А сточка build-depends в debian/control, конечно же, нужна совсем для другого.
> если я даю команду собрать пакет (например, через «обёртку» apt-src), зависимости
> будут установлены в процессе выполнения команды (будет запрошено повышение уровня привилигий,
> естественно)·Что за бред?
Пардон, перечитал внимательно, все вопросы сняты.
> А как, кстати, в Альте BuildRequires для пакета ставятся? Что выступает в
> качестве аналога urpmi --buildrequires [спек | SRPM]?В спеке прописываются BuildPreReq: . BuildRequires там ставить нельзя, иначе скрипт buildreq их затрет.
> В спеке прописываются BuildPreReq: . BuildRequires там ставить нельзя,
> иначе скрипт buildreq их затрет.К Вашему сведению, buildreq перетирает только первую строку BuildRequires после комментария специального вида (каковой сам и ставит перед сгенерированной строкой).
BuildPreReq: же применяется для указания сборочных зависимостей, требуемых для сворачивания src.rpm (например, доопределяющих макронабор пакетов).
Спасибо за дополнительный комментарий!
> А как, кстати, в Альте BuildRequires для пакета ставятся?http://www.altlinux.org/buildreq
> Что выступает в качестве аналога urpmi --buildrequires [спек | SRPM]?
Скорее уместней говорить о том, с чего его сдирали. :)
а разве мандрива не мертва? была же новость про банкротство
Речь была про компанию, а не про дистрибутив.
К тому же компания пока тоже не померла. И, думаю, не помрёт.
> а разве мандрива не мертва? была же новость про банкротствоЭто другая компания -- которая высказывалась в духе "ну и пусть себе французы банкротятся".
Пруфлинк будет?
>> а разве мандрива не мертва? была же новость про банкротство
> Это другая компания -- которая высказывалась в духе "ну и пусть себе
> французы банкротятся".www.rosalab.ru/blogs/zayavlenie-kompanii-rosa-o-situatsii-vok
>>> а разве мандрива не мертва? была же новость про банкротство
>> Это другая компания -- которая высказывалась в духе "ну и пусть себе
>> французы банкротятся".
> www.rosalab.ru/blogs/zayavlenie-kompanii-rosa-o-situatsii-vokЛюбопытный вброс и не менее любопытная трактовка :). А Вы пробовали просто читать новость, не домысливая того, что там нет?
Я ведь почему переспросил, потому что г-н Липатов, помнится, высказывался именно в описанном Вами ключе ("ну и пусть себе французы банкротятся"). Не, я, в принципе, понимаю, что ему "можно" :).
> Любопытный вброс и не менее любопытная трактовка :):)
> А Вы пробовали просто читать новость, не домысливая того, что там нет?
Многолетняя привычка сопоставлять различные источники и читать между строк.
> Я ведь почему переспросил, потому что г-н Липатов, помнится, высказывался именно в
> описанном Вами ключе ("ну и пусть себе французы банкротятся").Можно ссылку? Не вредности ради, а по возможности прочесть (если это писалось), чтоб понять смысл исходной фразы в контексте.
> Не, я, в принципе, понимаю, что ему "можно" :).
Да и Вам можно... "всё мне возможно, но не всё полезно".
Не думаю, что Виталик именно желал французам обанкротиться. Скорее (это моё предположение) тоже описывал наблюдаемое отношение к процессу.
>> Я ведь почему переспросил, потому что г-н Липатов, помнится, высказывался именно в
>> описанном Вами ключе ("ну и пусть себе французы банкротятся").
> Можно ссылку? Не вредности ради, а по возможности прочесть (если это
> писалось), чтоб понять смысл исходной фразы в контексте.Если мне не изменяет мой склероз, то было это в теме про банкротство Мандрива, где-то в январе. Один человек написал, что Роса спасает Мандриву от банкротства, а Липатов ему возразил - а зачем спасать? Подробнее искать сейчас времени нет, потому что с ребенком на руках это не очень удобно делать.
>>urpm-repomanageОчень нужная вещь. Жаль, требует новой версии urpmi и в 2010.2 перенести нельзя.
> По своим возможностям Urpm-tools очень близок к yum-utils, названия утилит и опции также схожи с yum-utils. Код проекта написан на языке PythonНу и зачем нужен очередной жручий тормоз?
Взяли бы быстрый сишный APT, и не сношали мозг своими велосипедами.
> Взяли бы быстрый сишный APTСтрого говоря, он плюсовый (и даже после рефакторинга не совсем реактивный, хотя и не тормоз).
> и не сношали мозг своими велосипедами.
А как же тогда Not Innovated Here? :]
Вы бы так явно не завидовали :). Ладно там аноним, но уж Вы-то должны понимать необходимость и пользу таких инструментов.
> Вы бы так явно не завидовали :)А что, есть чему? :)
> А что, есть чему? :)У вас таких инструментов нет.
Слова насчет HIN-синдрома поясните или так и оставите голословным обвинением?
> У вас таких инструментов нет.По функциональности APT ничуть не уступает сабжевой поделке.
А вот по жручести и тормознутости - это да, питоноподелия вне конкуренции.> Слова насчет HIN-синдрома поясните или так и оставите голословным обвинением?
Это не обвинение, а простая констатация факта.
> По функциональности APT ничуть не уступает сабжевой поделке.А как с помощью APT'а добиться функционала urpm-package-cleanup в плане удаления старых ядер? Можно ли как-то граф зависимостей построить?
И как найти и удалить пакеты, которые ставились руками и из сторонних репозиториев? Про Apt pinning знаю, знаю, как с его помощью задаунгрейдить систему. Но вот как описанного функционала добиться? Спрашиваю потому, что не так хорошо знаю apt/dpkg.
> А как с помощью APT'а добиться функционала urpm-package-cleanup в плане удаления
> старых ядер?Посмотрите apt-scripts -- если бы мне такое было нужно, то:
- убирал бы ядра из Allow-Duplicated в apt-conf и накропал вариант list-extras;
- или вообще обошёлся ещё более простой логикой на шелле.Впрочем, у меня нет такой нетерпимости к старым ядрам -- я-то уже знаю, зачем они бывают полезны на практике. Хотите, продолжайте бегать и хвастаться фичей, которая может оказаться сомнительной, а может просто завести в ловушку.
> Можно ли как-то граф зависимостей построить?
Уже несколько человек упомянули apt-cache dotty, посмотрите на досуге.
> И как найти и удалить пакеты, которые ставились руками и из сторонних репозиториев?
apt-get install apt-scripts
apt-cache list-extras
(ещё полезно list-nodeps)> Про Apt pinning знаю, знаю, как с его помощью задаунгрейдить систему.
> Но вот как описанного функционала добиться? Спрашиваю потому, что не
> так хорошо знаю apt/dpkg.http://www.altlinux.org/Downgrade (правда, это apt-rpm, но базовый синтаксис /etc/apt/preferences вроде не пострадал).
> Впрочем, у меня нет такой нетерпимости к старым ядрамЯ правильно понял, что Вы считаете нормальной ситуацию, когда в системе установлено 10-15 старых пакетов с ядрами?
>> Можно ли как-то граф зависимостей построить?
> Уже несколько человек упомянули apt-cache dotty, посмотрите на досуге.Нескольких человек не видел. Пакет посмотрю.
>> Про Apt pinning знаю, знаю, как с его помощью задаунгрейдить систему.
>> Но вот как описанного функционала добиться? Спрашиваю потому, что не
>> так хорошо знаю apt/dpkg.
> http://www.altlinux.org/Downgrade (правда, это apt-rpm, но базовый синтаксис /etc/apt/preferences
> вроде не пострадал).На самом деле, как раз про pinning я не спрашивал, но это я сам виноват, что не так написал. Вы на мой вопрос выше уже ответили. Спасибо.
>> Впрочем, у меня нет такой нетерпимости к старым ядрам
> Я правильно понял, что Вы считаете нормальной ситуацию, когда в системе установлено
> 10-15 старых пакетов с ядрами?pad:~> rpm -qa | grep kernel-image | wc -l
11
pad:~> echo $?
0:)
>>> Можно ли как-то граф зависимостей построить?
>> Уже несколько человек упомянули apt-cache dotty, посмотрите на досуге.
> Нескольких человек не видел. Пакет посмотрю.Виноват -- я было тоже набрал ответ, но перед отправкой заметил, что его уже дали (#3). Так что не двое, а действительно один.
re #34 -- на здоровье.
re #37 -- ммм... не обижайтесь, но если я решу, что есть организационный смысл вносить технические предложения -- то кому их изложить, и так знаю; но такого смысла не видно.Понимаете, это надо далеко не один год проработать над реальными проектами и самоокупаемостью, чтоб лучше себе представлять цену велосипедостроению (и бессмысленному, и вынужденному) да советам со стороны (пустым и не очень).
PS:
re #40 -- понял, не смею отвлекать; при надобности у него и уточню.
re #41 -- фраза "быстрая скорость" может быть хоть как-то осмыслена только как "быстро изменяющаяся скорость", т.е. если соотносить с ускорением. Аналогично и с остальными масляными маслами.
> Понимаете, это надо далеко не один год проработать над реальными проектами и
> самоокупаемостью, чтоб лучше себе представлять цену велосипедостроению (и бессмысленному,
> и вынужденному) да советам со стороны (пустым и не очень).Я вот как-то не вижу велосипедостроения. Просто к имеющейся пакетной системе прикрутили то, чего в ней не хватало и что уже было реализовано у других. У вас же в дистрибутиве сделали свои собственные alternatives, написанные на bash, если не ошибаюсь. Хотя можно было бы "не делать собственный велосипед" :).
> Просто к имеющейся пакетной системеВот-вот, и вроде бы понимая её состояние.
> прикрутили то, чего в ней не хватало и что уже было реализовано у других.
И понеслась весть о том по изданиям, большим и малым. :)
> У вас же в дистрибутиве сделали свои собственные alternatives,
> написанные на bash, если не ошибаюсь.Ошибаетесь, на sh -- см. шебанги (и в другой плоскости -- %changelog по слову awk).
> Хотя можно было бы "не делать собственный велосипед" :).
Уже не помню детали (inger@ их озвучивал), но перед тем, как переписывать софт, он обычно оочень много усилий прикладывал к исправлению имеющегося. И крайнюю меру старался не применять.
Если сильно интересно -- постараюсь найти тот анонс восьмилетней, что ли, давности.
Так что насчет NIH-синдрома? Или нам надо теперь, чтоб только Вас удовлетворить - бегом мчаться на apt-rpm мигрировать?
> А как с помощью APT'а добиться функционала urpm-package-cleanup в плане удаления старых ядер? Можно ли как-то граф зависимостей построить?В дебиане (как классическом представителе apt-систем) такая проблема отсутствует как класс, потому что там ядро не добавляется, а обновляется. А если бы и была такая проблема - пять минут с man aptitude, чтобы сформировать правильный запрос (в зависимости от того, как именно реализован ядрозоопарк).
> И как найти и удалить пакеты, которые ставились руками и из сторонних репозиториев?
aptitude search '?narrow(?installed, !?origin(Debian))!?obsolete'
>> А что, есть чему? :)
> У вас таких инструментов нет.Поимённо, пожалуйста.
> Вы бы так явно не завидовали :). Ладно там аноним, но уж Вы-то должны понимать необходимость и пользу таких инструментов.Даже какие-то там анонимы прекрасно понимают пользу и необходимость в создании "инструментов", которые тормозят и жрут память (при наличии быстрых, компактных и полнофункциональных альтернатив).
Ведь если пакетный менеджер будет работать быстро, у пользователей пропадет стимул покупать более мощный компьютер, что может негативно сказаться на мировой экономике (особенно на фоне экономического кризиса).
> Даже какие-то там анонимы прекрасно понимают пользу и необходимость в создании "инструментов",
> которые тормозят и жрут память (при наличии быстрых, компактных и полнофункциональных
> альтернатив).
> Ведь если пакетный менеджер будет работать быстро, у пользователей пропадет стимул покупать
> более мощный компьютер, что может негативно сказаться на мировой экономике (особенно
> на фоне экономического кризиса).У Вас первое предложение противоречит второму. Думаю, что просто потому, что Вы не знаете, как устроена Mandriva. Пакетный менеджер написан на perl (и это является наследием Mandriva), как и многие системные инструменты. Работает достаточно быстро. Если хотите помочь переписать это все на "православном" С- welcome!
Urpm-tools обслуживают специфические задачи, касающиеся управления пакетами. Кстати, посоветуйте альтовцам переписать свой update-kernel с тормозного bash на "что-нибудь быстрое". Ответ даже интересен. Скорость работы urpm-tools для выполнения поставленных им задач также быстрая. Большего от них не требуется.
> Работает достаточно быстро.Достаточно - понятие относительное. yum тоже работает "достаточно быстро" :D
> Если хотите помочь переписать это все на "православном" С- welcome!
Нет, не хочу. Ведь есть более вменяемые дистрибутивы, не страдающие NIH-синдромом, например, Debian.
А в мандриве рано или поздно, в рамках борьбы с тяжелым наследием темных лет, перепишут urpmi на православном питоне.> Urpm-tools обслуживают специфические задачи, касающиеся управления пакетами. Кстати,
> посоветуйте альтовцам переписать свой update-kernel с тормозного bash на "что-нибудь быстрое".Баш - это вам не пистон. Когда людям требуются _феерические_ тормоза и огромное потребление ресурсов - они выбирают питон, и он в полной мере оправдывает эти надежды. bash значительно уступает ему в этом плане (его тормоза проявляются, когда счет идет на единицы секунд, а не на минуты, как в yum).
> Скорость работы urpm-tools для выполнения поставленных им задач также быстрая. Большего от них не требуется.
То же самое можно сказать и про yum. И прозвучит это так же смешно :)
> А в мандриве рано или поздно, в рамках борьбы с тяжелым наследием
> темных лет, перепишут urpmi на православном питоне.Делать больше нечего. Насколько я знаю, таких планов нет и не предвидится.
> Если хотите помочь переписать это все на "православном" С- welcome!Думаю, у меня есть более интересное предложение для тех, кому действительно охота приложить напильник в данной предметной области.
> Urpm-tools обслуживают специфические задачи, касающиеся управления пакетами.
> Кстати, посоветуйте альтовцам переписать свой update-kernel с тормозного bashИ в чём bash не устроил -- с учётом отсутствия сколь-нибудь тяжёлой логики на нём?
http://git.altlinux.org/gears/u/update-kernel.git?p=update-k...
Там можно оптимизировать по количеству вызовов апта, но потеряется транзакционность. Или переписать с использованием apt-pipe. Но тут есть ...см. выше ;-)
> Скорость [...] быстрая.
На всякий: скорость не бывает быстрой, температура -- холодной, цена -- дешёвой. Если не пытаться соригинальничать насчёт второй производной (что всё равно мало кто оценит, поскольку неграмотное использование подобных связок слишком распространилось).
> Если не пытаться соригинальничать насчёт второй производной (что всё равно
> мало кто оценит, поскольку неграмотное использование подобных связок слишком распространилось).А к чему тут вторую производную приплетать? :) Для наукообразности? :).
