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

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

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

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

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

снапшоты в btrfs

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

btrfs

Ненужно

fix

Это не фикс, это брейк.

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

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

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

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

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

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

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

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

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

https://launchpad.net/apt-btrfs-snapshot

С другой стороны, очень большое кол-во пользователей выбирает ext4, привязка к определенной ФС не есть хорошо.

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

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

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

А-ля git, начальный образ и потом сохраняет изменения?

В точку.

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

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

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

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

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

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

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

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

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

И сколько тратишь на снапшоты? Гигов в 20-30 можно уложиться?

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

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

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

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

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

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

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

рпмопрблемы

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

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

Никак ::)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как ты быстро перешёл на личности.

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

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

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

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

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

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

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

Костыльненько.

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

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

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

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

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

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

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