Атомарный апгрейд и удаление rpm пакетов

Проблема в том что rpm за раз делает только одно действие — или устанавливает или удяляет.

Это точно rpm? Ведь есть же ″rpm -U″.

А так, можно написать скрипт, считающий все зависимости. Но вобще не понятна начальная постановка задачи, кто-то эти наборы пакетов составлял или они взяты от балды и могут как угодно конфликтовать?

Это точно rpm? Ведь есть же ″rpm -U″.

имеется ввиду что нельзя в одной команде делать и --upgrade и --erase (для удаления конфликтного пакета)

А так, можно написать скрипт, считающий все зависимости. Но вобще не понятна начальная постановка задачи, кто-то эти наборы пакетов составлял или они взяты от балды и могут как угодно конфликтовать?

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

Атомарных обновлений сейчас не существует ни в одном Linux-дистрибутиве. Чтоб добиться их нам нужна

а) файловая система с поддержкой транзакций (LVM2, btrfs, zfs) б) поддержка этой системы в пакетных менеджерах (это скорее всего приведет к неподдерживаемости всех прочих fs, что в принципе терпимо)

Альтернативой может служить обновление через создание второй файловой системы и переключение на нее во время перерезагрузки (как это делается в ChromeOS и телефонных операционках, вроде-бы). Например, в Fedora в будущем планируется именно этот путь - мы будем использовать systemd для этого.

Но есть еще и третья проблема - атомарный апдейт потребует «Checkpoint/Restore» ряда приложений. Работа по интеграции этой технологии только планируется для RPM .

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

ого, ну ты круто взял ) я имел ввиду атомарность не на файловом уровне, а хотя бы на уровне пакетного менеджера. То есть переход из одного безконфлитного состояния в другое без промежуточных этапов и ключиков --force и --nodeps

поддержка этой системы в пакетных менеджерах (это скорее всего приведет к неподдерживаемости всех прочих fs)

Нет, не привёдет.

Если конечно не Поттеринг делать будет.

И поддержка ПМ, вообще, не нужна.

То есть переход из одного безконфлитного состояния в другое без промежуточных этапов и ключиков --force и --nodeps

Я бы реализовал бы трюк с двумя рутовыми fs. Вместо обновления текущей корневой фс производи обновление (или вообще переформатирование и полную переустановку) дублирующей fs, перезагружайся, переключаясь на нее в параметре загрузки ядра. По-другому какую-то атомарность с роллбэками - в общем случае не получится. Если тщательно рассмотреть типичный апдейт вашей системы, то может и получится, но я б не стал на это закладываться, особенно в потребительском продукте (роутер, телефон, телевизор, интернет-шлюз и т.п.).

Вот смотри - смысл пакетов в проверках зависимостей, а вы обязательно упретесь при поломках, что откатиться не получится, т.к. часть зависимостей уже переустановлена, и вам надо не просто откатить поломавшийся пакет, а еще и его зависимости (и их зависимости, и откатить пакеты, которые от них зависят и т.п.). У тебя есть вариант - отключить проверку зависимостей, но RPM тут недаром тебе семафорит, т.к. ты «откатишься» (это не полный роллбэк, т.к. зависимости ты не откатишь просто так, как я уже сказал) на заведомо нерабочее состояние.

имеется ввиду что нельзя в одной команде делать и --upgrade и --erase (для удаления конфликтного пакета)

И не надо. Если новому пакету в spec'е указать, что он

Conflicts: package1 package2 package3

Точно? А у меня само не удаляет:

# rpm -i openssh-*
error: Failed dependencies:
       dropbear conflicts with openssh-6.0p1-r3.core2
       dropbear conflicts with openssh-sshd-6.0p1-r3.core2

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

ИМХО, тяжело будет запиливать.

А если помимо

Conflicts:

Updates:

Obsoletes:

Хотелось бы избежать модификации пакетов, тем более что dropbear например записывать в obsoletes было бы неправильно — это скорее альтернативный (к openssh) пакет.

Сейчас смотрю на deb — может получится через package selection запилить.

Забавно — apt-get походу сам трекает все зависимости, а потом вызывает несколько раз dpkg с ключиками --force-*

Может и не туда, но, вроде как вам нужен ″yum shell″. Вроде как ему можно указать сразу что ставить и что удалять и он может в одной транзакции заменить альтернативные пакеты (один поставить, а другой удалить).

Нужно использовать yum, а не rpm. Удалить все из первой директории, установить из второй. Элементарно.

Да, yum бы наверное подошел. Жаль только что у нас его нет )