Urpm-tools - набор утилит для инструментария urpmi

[Juliette]

Компания РОСА представляет первую версию Urpm-tools - набора утилит, расширяющих и дополняющих функциональность инструментария urpmi. Разработчики и пользователи дистрибутивов давно ожидали выхода этого комплекта: его составляющие отлично дополняют имеющийся инструментарий и являются прекрасными помощниками в работе.
Пользователям дистрибутивов, использующих Urpmi, будет интересна утилита urpm-package-cleanup, занимающаяся поиском проблем в установленном наборе пакетов и чисткой системы. В частности, утилита поможет найти пакеты с несколькими установленными версиями и удалить устаревшие, определить, какие из установленных пакетов больше не присутствуют в репозиториях, а также выявить пакеты, для которых отсутствуют обязательные или мягкие зависимости.
Urpm-downloader позволяет скачивать из онлайн-репозиториев пакеты со всеми необходимыми зависимостями. Этот инструмент будет полезен как разработчикам при формировании собственных репозиториев, так и пользователям, желающим скачать весь необходимый набор пакетов с целью дальнейшей его установки с локального источника.
Утилиты urpm-repoclosure и urpm-repodiff предназначены для разработчиков, создающих репозитории для Urpmi. Urpm-repoclosure проверяет замкнутость репозитория по зависимостям, позволяя убедиться в самодостаточности репозитория и гарантировать, что для установки пакетов из него не потребуется подключения других источников. Программа urpm-repodiff позволяет получить детальную информацию о различиях двух репозиториев – перечень добавленных и удаленных пакетов, а также список модифицированных пакетов с описанием различий (на основе журналов изменений).
В ближайшем будущем мы планируем добавить в этот набор еще ряд полезных инструментов, следите за новостями!
Подробное описание: http://wiki.rosalab.ru/index.php/Urpm-tools.

Оригинал новости

[ans]

Компания РОСА представляет первую версию Urpm-tools - набора утилит, расширяющих и дополняющих функциональность инструментария urpmi. Разработчики и пользователи дистрибутивов давно ожидали выхода этого комплекта: его составляющие отлично дополняют имеющийся инструментарий и являются прекрасными помощниками в работе.
Оригинал новости

Так держать!

[ManDrive]

Не получится ли тоже самое как с удалением сирот - удаляя сироты удаляется полсистемы по зависимостям?!

[Hooliganos]

Не получится ли тоже самое как с удалением сирот - удаляя сироты удаляется полсистемы по зависимостям?!

Так и будет. Вряд ли Urpm-tools принципиально отличается от старого urpm. Написано, что "расширяющих и дополняющих функциональность".
Об изменениях существующего не сказано.

Видимо это непосильная задача - для каждого пакета составить список приложений, использующих его.
Если список пуст - можно удалить пакет. Если нет - не трогать его. И не записывать в осиротевшие на основании того, что удалена одна из множества программ, использующих этот пакет.

[Bizdelnick]

Не получится ли тоже самое как с удалением сирот - удаляя сироты удаляется полсистемы по зависимостям?!

А нефиг метапакеты сносить. Если снесли - ССЗБ, получайте вполне закономерный результат.

[Hooliganos]

Какая разница, мета или не мета? Исходя из чего urpmi заносит в списки осиротевших (и предлагает удалить их) пакеты, используемые другими приложениями (в т.ч. и теми, без которых система не загрузится) ?
Внятный ответ на этот вопрос есть?

[Bizdelnick]

Исходя из чего urpmi заносит в списки осиротевших (и предлагает удалить их) пакеты, используемые другими приложениями (в т.ч. и теми, без которых система не загрузится) ?

Что за пакеты? Номер бага на qa.mandriva.com?

[Hooliganos]

Исходя из чего urpmi заносит в списки осиротевших (и предлагает удалить их) пакеты, используемые другими приложениями (в т.ч. и теми, без которых система не загрузится) ?

Что за пакеты? Номер бага на qa.mandriva.com?

Первый раз я удалял firefox, после удаления было предложено удалить осиротевшие пакеты. Пакетов было достаточно много, поименно не помню (два года уже прошло), помню, что были среди пакетов куча разных либ, пакеты kde. Ну я и доверился, подумал, что действительно не нужны. Удалил, перезагрузился и попал в very limited shell. Что это такое , объяснять, думаю, не надо. Пришлось переустанавливать систему.
Второй раз тоже (это был опенофис) предложили удалить сирот. Помня про случай с firefox, все предложенное удалять не стал, просмотрел список и удалил те, которые (судя по названиям) имели отношение только к офису. Система не упала, но куча прог отказалась работать: в основном были отсутствующие модули, нестыковка версий и т.д. В итоге опять оказалось проще и надёжней переустановиться.

Номер бага не знаю, если интересно, воспроизведите эксперимент сами: удалите пару-тройку тяжёлых приложений, например firefox, openoffice, gimp и когда будет предложено удалить осиротевшие пакеты, согласитесь. А потом расскажете, что стало с вашей системой.
Если не рискнете, то просто почитайте:
http://www.google.ru/#sclient=psy-ab&h...280&bih=868

[verg]

От удаления firefox, openoffice, gimp и последующего удаления пакет-сирот мандрива не ломается.
Проверено "сто" раз.
Ищите проблему в другом месте. Urpm-tools - набор утилит для инструментария urpmi

Ну я и доверился, подумал, что действительно не нужны

Доверяй, но проверяй.
Есть же форумы - можно было и спросить знающих людей, если есть сомнения по поводу тех или иных действий.
Тем более, что перед удалением пакетов-сирот высвечивается их список.

[verg]

По теме:
Эта команда вообще опасная: urpm-package-cleanup и наоборот интереса вызывать не должна , особенно кто ставит пакеты со сторонних реп и с ручной установки.
Лучше уж эту использовать: urpme --auto-orphans (только с умом, а не как Hooliganos )

[Bizdelnick]

Первый раз я удалял firefox, после удаления было предложено удалить осиротевшие пакеты.

Прекрасно. Какие пакеты, зависящие от firefox, удалились вместе с ним, Вы, конечно же, не посмотрели?
Стандартные десктопные приложения входят в те или иные метапакеты, так что это именно тот случай, когда ССЗБ. Либо не удаляйте в таких случаях сирот, либо разбирайтесь досконально, какой пакет для чего нужен, и делайте urpmi для всех сирот, которые должны остаться в системе.

P. S. Я не утверждаю, что --auto-orphans работает идеально: в кукере он предлагал мне снести пакеты, которые сам же потом отказывался удалять, потому что от них что-то зависит. Но то кукер.

[Hooliganos]

Народ, вы ставите телегу впереди лошади. Я понимаю ваш линуксовый патриотизм, но надо бы и какой-то минимум объективности иметь.
Есть команда urpme --auto-orphans, и она не предполагает, что пользователь должен изучить всё дерево зависимостей и потом решить, какие пакеты нужны, а какие нет. Во-первых, пакетов огромное количество и проследить их взаимосвязь в ручную - задача нетривиальная. Во-вторых, пользователь может оказаться совсем и не спецом в области пакетостроения и банально не сможет определить, что нужно, а что можно удалить.
Для этого urpme --auto-orphans и существует. Не пользователь должен анализировать, а программа. Опция auto предполагает автоматическую обработку зависимостей без вмешательства пользователя.

[akdengi]

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

[VictorR2007]

По теме:
Эта команда вообще опасная: urpm-package-cleanup и наоборот интереса вызывать не должна , особенно кто ставит пакеты со сторонних реп и с ручной установки.
Лучше уж эту использовать: urpme --auto-orphans (только с умом, а не как Hooliganos )

Да вроде urpm-package-cleanup достаточно безобидна.
Недавно её смотрел. У меня установлен KDE 4.7.4 и она мне выдала список либ оставшихся от KDE 4.7.3, которые не видела
urpme --auto-orphans, и после команды на их удаление ненужные удалила.

[Bizdelnick]

Для этого urpme --auto-orphans и существует. Не пользователь должен анализировать, а программа. Опция auto предполагает автоматическую обработку зависимостей без вмешательства пользователя.

Она и обрабатывает зависимости. Вполне себе автоматически. Но искусственным интеллектом не наделена, и для её использования надо понимать, как она работает. Не понимаете - не пользуйтесь, угробите систему. Это не хомячковый инструмент.

[DrakSoul]

Какая разница, мета или не мета? Исходя из чего urpmi заносит в списки осиротевших (и предлагает удалить их) пакеты, используемые другими приложениями (в т.ч. и теми, без которых система не загрузится) ?
Внятный ответ на этот вопрос есть?

Реальный ответ не последует. Потому, что, как таковой структуры нет! Все носит хаотичный характер,
и никто реального представления не имеет! Это венигрет с исходной точой - ядром. С которым, так же, не так все просто! То что есть, носит примитивный характер, в связи с архаичными представлениями. Ценность каждого пакета - его содержание.
От понятия дерева зависимостей уже давно следовало бы отойти, И расматривать как многомерную структуру построения, в многоплановом строении. Необходимо вносить новые принципы и переписывать все с нуля. Этого делать никто не будет!

Если поставили и работает - не трогать! А на все остальное забейте!
В даном случае, чтобы получить что-то другое - проще переставить.

З.Ы.
Это мое личное мнение! Изменять его, или подгонять его, под чужие представления я не буду.

[skok]

Видимо это непосильная задача - для каждого пакета составить список приложений, использующих его.
Если список пуст - можно удалить пакет. Если нет - не трогать его. И не записывать в осиротевшие на основании того, что удалена одна из множества программ, использующих этот пакет.

А интересно, кто должен писать этот список? Производители "тысячи и одной" программы на основе общих библиотек или производители этих самых библиотек, на основе которых пишется "тысяча и одна" программа?
Вы представляете себе обьём работы. И ментейнеры пакетов должны следить за актуальностью сего списка?
тому кто захочет занятся сим неблагодарным трудом, работа обеспечина, пока живо СПО.

- Дзынь, дзынь.. "Ало, здраствуйте, Вася Програмиров, нас интересует тот аудиоплеер , который вы написали как дипломную работу в институте. Он ещё поддерживается вами?"
"Вы что!? Я уже десять лет как в Майкрософт работаю......."

[SinClaus]

Кто-нибудь может членораздельно объяснить, зачем удалять "сирот"? Объёмы, занимаемые ими смехотворно малы, жить они никому не мешают, что зудит-то?

[akdengi]

Кто-нибудь может членораздельно объяснить, зачем удалять "сирот"? Объёмы, занимаемые ими смехотворно малы, жить они никому не мешают, что зудит-то?

Они с ними [сироты] разговаривают. И спать мешают.

[verg]

Кстати мысль: Если бы пакетный менеджер urpmi/rpmdrake не призывал бы постоянно при случае к удалению "сирот"(была бы скрыта от любопытных глаз), то и этой "проблемы" бы и не было, раз уж такая функция "небезопасная"и ненужная простому юзеру.

з.ы. многих мучает этот вопрос: https://forums.mageia.org/en/viewtopic.php?f=15&t=31

[Bizdelnick]

Чисто теоретически можно зависимости от программ, которые наиболее часто удаляются, в метапакетах сделать мягкими. Но это всё равно не панацея, да и поди угадай, что кому взбредёт в голову удалить.

Upd. Хотя... Не вижу серьёзных препятствий для того, чтобы во всех метапакетах использовать suggests вместо requires. В большинстве случаев это должно решить проблему с сиротами.

[den_beckett]

Кстати мысль: Если бы пакетный менеджер urpmi/rpmdrake не призывал бы постоянно при случае к удалению "сирот"(была бы скрыта от любопытных глаз), то и этой "проблемы" бы и не было, раз уж такая функция "небезопасная"и ненужная простому юзеру.

Для простого юзера вообще надо оставить три кнопки "Интернет", "Музыка", "Прон", и все. А все остальное убрать, чтоб не смущало неокрепшие умы. И все это приправить нескучными обоями и иконками и революционным планшетным интерфейсом нового типа.

[taaroa]

den_beckett
rosa 2014 → http://u.pikucha.ru/i78N5/rosa2014.jpeg (50483 байт)

[olelukoie]

Какая разница, мета или не мета? Исходя из чего urpmi заносит в списки осиротевших (и предлагает удалить их) пакеты, используемые другими приложениями (в т.ч. и теми, без которых система не загрузится) ?
Внятный ответ на этот вопрос есть?

Реальный ответ не последует. Потому, что, как таковой структуры нет! Все носит хаотичный характер,
и никто реального представления не имеет! Это венигрет с исходной точой - ядром. С которым, так же, не так все просто! То что есть, носит примитивный характер, в связи с архаичными представлениями. Ценность каждого пакета - его содержание.
От понятия дерева зависимостей уже давно следовало бы отойти, И расматривать как многомерную структуру построения, в многоплановом строении. Необходимо вносить новые принципы и переписывать все с нуля. Этого делать никто не будет!

Если поставили и работает - не трогать! А на все остальное забейте!
В даном случае, чтобы получить что-то другое - проще переставить.

З.Ы.
Это мое личное мнение! Изменять его, или подгонять его, под чужие представления я не буду.

Поскольку дискуссия зашла так далеко, вставлю свои пять копеек.

Итак, вот алгоритм (примерный) определения сирот в мандриве:

1. Пакет, установленный вручную, НЕ попадает в список сирот.
2. Мета-пакет, установленный при установке системы, НЕ попадает в список сирот.
3. Пакет, входящий в цепочку зависимостей (как минимум жестких, т.е. Requires, но возможно и мягких, т.е. Suggests) одного из пакетов, входящих в одну из первых двух групп (установлен вручную или метапакет, установленный при установке системы), также НЕ попадает в список сирот.
4. Все остальные пакеты - сироты.

Я не знаю точно, как обстоят дела с зависимостями типа Suggests (мягкие зависимости) и мета-пакетами, установленными как зависимости других мета-пакетов (наример, что будет с task-kde-minimal после удаления task-kde).

[olelukoie]

Чисто теоретически можно зависимости от программ, которые наиболее часто удаляются, в метапакетах сделать мягкими. Но это всё равно не панацея, да и поди угадай, что кому взбредёт в голову удалить.

Upd. Хотя... Не вижу серьёзных препятствий для того, чтобы во всех метапакетах использовать suggests вместо requires. В большинстве случаев это должно решить проблему с сиротами.

Способов решения проблемы много, но у всех есть как достоинства, так и недостаки.

Мне представляется оптимальным вариант, когда базовые компоненты каждой подсистемы, необходимые для ее нормального функционирования, были бы выделены в отдельные базовые мета-пакеты, и эти мета-пакеты никогда не попадали бы в категорию сирот, а при попытке их удалить вручную выдавалось бы соответствующее предупреждение о возможных последствиях (типа "внимание. удаление этого пакета может привести к неработоспособности рабочей среды KDE"). А вот пользовательские приложения - да, их лучше всего прописывать как suggests для соотвествующих мета-пакетов более высокого уровня.
Одновременно можно было бы добавить групировку мета-пакетов по типу, например группу мета-пакетов типа desktop environment, при удалении такого мета-пакета проверять наличие в системе других мета-пакетов этой же группы, и если таковых не окажется, то тоже выдавать соответствующее предупреждение (типа "осторожно, после удаления этого пакета в системе не останется ни одного работоспособного DE").

[Bizdelnick]

Мне представляется оптимальным вариант, когда базовые компоненты каждой подсистемы, необходимые для ее нормального функционирования, были бы выделены в отдельные базовые мета-пакеты, и эти мета-пакеты никогда не попадали бы в категорию сирот,

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

выдавалось бы соответствующее предупреждение

Не-не-не, хватит идиотских предупреждений и так. Нубы всё равно не поймут, о чём речь, и будут ругаться, как в этом вашем линупсе всё сложно, а опытный пользователь, как правило, отдаёт себе отчёт, что он делает. Промежуточная прослойка, которой такие предупреждения помогли бы, очень невелика.

[taaroa]

выдавалось бы соответствующее предупреждение

Не-не-не, хватит идиотских предупреждений и так. Нубы всё равно не поймут, о чём речь, и будут ругаться, как в этом вашем линупсе всё сложно, а опытный пользователь, как правило, отдаёт себе отчёт, что он делает. Промежуточная прослойка, которой такие предупреждения помогли бы, очень невелика.

+1 ага, именно поэтому over50% тем на гентушных форумах (или соответствующих разделах форумов) от элементарного не чтения выхлопа emerge.
странно ожидать от хомячка aka простой пользователь пк ™ втыкания в какие-то там blah-after-blah-u-need-restart-etc.

[den_beckett]

+1 ага, именно поэтому over50% тем на гентушных форумах (или соответствующих разделах форумов) от элементарного не чтения выхлопа emerge.
странно ожидать от хомячка aka простой пользователь пк ™ втыкания в какие-то там blah-after-blah-u-need-restart-etc.

Есть такое мнение, что если бы эти сообщения не терялись бы в "выхлопе emerge", то их таки бы читали. Если для сего не предусмотрена нативная возможность, и надо ставить посторонние утилиты, то проблема не в юзверях, не?

[taaroa]

den_beckett
ok. знаете за что (не люблю писать "я") я уважаю майкрософт? вот именно, за то самое. апдейты пришли, перезагрузка, профит. заметьте, апдейты очень редко убивают систему.
два раза за более чем десять лет. на моей памяти.
вывод первый: qa + база (реестр) рулят. реестр не только в виндовс есть, кстати.
вывод второй: в этом вашем линупксе, в отличие от, отвечают за полную базу по aka репозиторий. почувствуйте разницу. только в восьмой nt это начинает появляться.
выдохнул.

[den_beckett]

в этом вашем линупксе, в отличие от, отвечают за полную базу по aka репозиторий. почувствуйте разницу.

Я таки все равно не понимаю, как это мешает прикрутить к portage более-менее вменяемую систему уведомлений пользователя. О том же elogv(iewer) надо еще узнать. И не сказать, чтобы и там было удобно сделано. А ведь таки да, сколько бы проблем можно было решить. Даже не решить, а предотвратить, бо ты правильно говоришь, значительная часть вопросов на форумах, рассылках и багзилле от этого и происходит. Но - никому не надо. Добровольных помощников, готовых в сотый раз отвечать на один и тот же вопрос на форумах хватает => разрабам можно ишшо несколько лет не чесаться.