LINUX.ORG.RU

Разработчики дистрибутива ROSA представили утилиту urpmi.recover

 , ,


2

3

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

Откатывать пакеты вручную не очень удобно, особенно если их много и вы не вполне уверены, что именно надо откатить для возврата системы в нормальное состояние. На помощь может прийти urpm-reposync, но этот инструмент может оказаться слишком мощным — он осуществит полную синхронизацию вашей системы с подключенными репозиториями, и откатить только часть пакетов с его помощью затруднительно.

Теперь ниша между ручным откатом пакетов и использованием reposync заполнена утилитой urpmi.recover, способной откатывать установленные вами пакеты. Urpmi.recover может вернуть пакетную базу в состояние на определенную дату в прошлом, либо откатить заданное количество транзакций по установке пакетов.

>>> Подробности

anonymous

Проверено: Shaman007 ()
Последнее исправление: Shaman007 (всего исправлений: 1)

Текст в блоге разработчиков распространяется на условиях свободной лицензии CC-BY-SA, поэтому я взял его без изменений.

anonymous
()

Ты ба, urpmi еще живое

shimon ★★★★★
()
Ответ на: комментарий от tazhate

Что люди только не делают, лишь
бы не использовать снапшоты в btrfs.
//fix
тем более у суси есть гуй и интеграция в zypper

Novell-ch ★★★★★
()
Ответ на: комментарий от Novell-ch

снапшоты в btrfs

очень глючное поделие, всё заканчивается невозможностью починить раздел

anonymous
()
Ответ на: комментарий от Novell-ch

Что только люди не делают, лишь бы не использовать user-tag'и

alozovskoy ★★★★★
()
Ответ на: комментарий от tazhate

Что люди только не делают, лишь бы не использовать снапшоты в zfs.

Это прекрасный микроскоп для того, чтобы откатить два пакета.

Aceler ★★★★★
()
Ответ на: комментарий от Aceler

Это прекрасный микроскоп для того, чтобы откатить два пакета.

Бред ты какой-то сказал. Делается одной командой, другой возвращается если что. Всё.
Причем тут микроскоп?

tazhate ★★★★★
()
Ответ на: комментарий от tazhate

Ты правда перед обновлением каждого пакета снапшот создаёшь?

Если да, то что-то это мне напоминает... «Создаётся контрольная точка восстановления на случай»

vitalif ★★★★★
()
Ответ на: комментарий от tazhate

Причем тут микроскоп?

Некоторые им гвозди забивают :) Намек на то, что странно откатывать целую ФС ради двух маленьких (или не очень) пакетов.

ArtKun ★★★★★
()

Urpmi.recover может вернуть пакетную базу в состояние на определенную дату в прошлом

А для деба есть что-нибудь подобное, кроме собственноручного огорода баш-скриптов?

MyFreedom ★★★
()
Ответ на: комментарий от tazhate

А какой принцип у снапшотов? Имеется в виду в плане потребления памяти на HDD. А-ля git, начальный образ и потом сохраняет изменения?

ekzotech ★★★★
()
Ответ на: комментарий от ArtKun

Некоторые им гвозди забивают :)
Намек на то, что странно откатывать целую ФС ради двух маленьких (или не очень) пакетов.

Я прекрасно понял, что он имел ввиду. Мне хочется услышать ответ от бэна.

tazhate ★★★★★
()
Ответ на: комментарий от vitalif

Ты правда перед обновлением каждого пакета снапшот создаёшь?

А в чем проблема? Ты точно знаешь, насколько они легкие и воздушные в zfs?

«Создаётся контрольная точка восстановления на случай»

Да, только вот в моем случае откат фс делается за несколько миллисекунд. А вот точечка восстановления может и часами работать.

tazhate ★★★★★
()
Ответ на: комментарий от tazhate

А вот точечка восстановления может и часами работать.

Microsoft Windows. Думай о вечном.

der_looser ★★
()

Нет чтоб перейти на click-пакеты от Ubuntu, они же наверняка уже широко используются в мобильной Ubuntu... И не надо никакие поломки фиксить.

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от tazhate

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

Ttt ☆☆☆☆☆
()

Интересно, как они решают проблему с тем, что какой-то из пакетов, установленных ранее, более недоступен в репозиториях?

p.s. Штука на самом деле очень нужная, реализовывал несколько лет назад в AgiliaLinux в виде mpkg-rollback, но работало кривовато, в первую очередь из-за вышеупомянутой проблемы.

aix27249
()
Ответ на: комментарий от tazhate

Причем тут микроскоп?

Микроскоп — это такой инструмент для забивания гвоздей. Мигрировать на zfs ради отката пакетов — это серьёзный ход.

Aceler ★★★★★
()

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

рпмопрблемы

anonymous
()
Ответ на: комментарий от aix27249

Интересно, как они решают проблему с тем, что какой-то из пакетов, установленных ранее, более недоступен в репозиториях?

Для Ъ: Для осуществления такого отката пакетов, urpmi.recover сохраняет старые версии обновляемых пакетов в директории /var/spool/repackage.

Aceler ★★★★★
()
Ответ на: комментарий от Ttt

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

А разве твои данные хранятся на том же разделе, что и пакеты?

anonymous
()

Так этой штуке же уже лет дцать. Помнится, ещё в Mandriva 2008 ей пользоваться пытался, но из-за долгого repack и отъедания места на диске отказался.

anonymous
()
Ответ на: комментарий от Ttt

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

А в снапшот разве нельзя положить отдельный файл?

Aceler ★★★★★
()
Ответ на: комментарий от ekzotech

И сколько тратишь на снапшоты?

Зависит от данных же.

tazhate ★★★★★
()
Ответ на: комментарий от Aceler

Мигрировать на zfs ради отката пакетов — это серьёзный ход.

Кроме отката пакетов через веселое решение, там и так огромное кол-во плюсов из-за которых стоит переходить всем.

tazhate ★★★★★
()
Ответ на: комментарий от vitalif

Я не говорю что проблема - я говорю, ты реально это делаешь? O_O

Нет конечно, у меня просто не встает проблемы даунгрейда пакетов.

tazhate ★★★★★
()
Ответ на: комментарий от Aceler

А в снапшот разве нельзя положить отдельный файл?

Вот блин, и правда нельзя. Ну тогда это совсем весело.

Aceler ★★★★★
()
Ответ на: комментарий от tazhate

Кроме отката пакетов через веселое решение

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

Aceler ★★★★★
()
Ответ на: комментарий от tazhate

А нахрен данные в этот момент копить, ы?

Use-case: я поставил туеву хучу dev-пакетов. Три дня делал из системы генту^w^w^w^w собирал ушибленный софт, который очень нужен. Теперь мне надо все эти dev-пакеты снести.

С твоими снапшотами я снесу их вместе с моим софтом. Или мне каждую директорию отдельно монтировать и снапшотить?

Aceler ★★★★★
()
Ответ на: комментарий от tazhate

там и так огромное кол-во плюсов из-за которых стоит переходить всем.

А к этой части претензий нет, кроме правовых проблем в юридически отсталых странах.

Aceler ★★★★★
()
Ответ на: комментарий от Aceler

Use-case: я поставил туеву хучу dev-пакетов. Три дня делал из системы генту^w^w^w^w собирал ушибленный софт, который очень нужен. Теперь мне надо все эти dev-пакеты снести.

Отвратный юзкейс, раз ты все это говно на локалхосте держишь.
А если говорить про северные подобного плана проблемы, всегда есть docker.

tazhate ★★★★★
()
Ответ на: комментарий от Ttt

Ну настройки и логи обычно там же хранятся.

Настройки и логи откатятся до того момента, когда система была рабочей. Это хорошо, не?

anonymous
()
Ответ на: комментарий от anonymous

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

Ttt ☆☆☆☆☆
()
Ответ на: комментарий от Ttt

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

Я таки не очень понимаю, зачем вносить изменения не касающиеся данных пакетов, если данные пакеты ещё не протестированы, но ок.

anonymous
()
Ответ на: комментарий от Aceler

Да правда отвратный юзкейс. Но даже так все просто. Либо снеси свои -dev пакеты руками, либо сохрани текущие наработки ro-снапшотом, откати взад / до позавчерашнего снапшота и в будущем устраивай эти ужасы в виртуалке. И не лепечи, что откате снапшота твои самоделки якобы куда-то обязательно канут. А вот авторы сабжевого поделия, как мне кажется, именно поломками сервисов при апдейтах интересуются, а не этими твоими фантазиями.

t184256 ★★★★★
()

…лишь бы не использовать yum.

Gotf ★★★
()
Ответ на: комментарий от tazhate

Что люди только не делают, лишь бы не использовать снапшоты в zfs.

ZFS ущербна by design (медленное и может только разрастаться, а сжиматься - нет). РМС не одобряет (лицензия позволяет ввести тебе анальный зонд).

Harzah2
()
Ответ на: комментарий от Aceler

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

t184256 ★★★★★
()
Ответ на: комментарий от t184256

И не лепечи, что откате снапшота твои самоделки якобы куда-то обязательно канут.

А при откате снапшота они не канут? Так есть в ZFS пофайловый снапшот или только вся ФС?

А вот авторы сабжевого поделия

Авторы сабжевого поделия больше рассчитывают на юзкейс вида «поставили что-то свежее не из основного репозитария, а потом надо всё откатить назад, безо всяких снапшотов». Для чего сохраняют старые версии библиотек.

Aceler ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.