Предлагаю убрать у system-backup зависимости на утилиты для поддержки файловых систем: btrfs-progs, jfsutils, xfsprogs. Поддержка файловых систем должна определяться по наличию в образе.
Они используются для получения дополнительной информации при снятии бэкапа. Если их не будет в образе, бэкап будет либо не полным, либо его не получится сделать совсем. И то, и другое противоречит задаче программы. Можно исключить system-backup из тех образов, где этого не требуется. Например, ей нечего делать в основной системе Simply Linux.
(Ответ для Leonid Krivoshein на комментарий #1) > Они используются для получения дополнительной информации при снятии бэкапа. > Если их не будет в образе, бэкап будет либо не полным, либо его не получится > сделать совсем. И то, и другое противоречит задаче программы. Можно > исключить system-backup из тех образов, где этого не требуется. Например, ей > нечего делать в основной системе Simply Linux. Наличие в образе определяется сборщиком образа.
(In reply to Антон Мидюков from comment #2) > Наличие в образе определяется сборщиком образа. Тут надо подумать, так как зависимости на самом деле нужные. Теоретически их можно сделать более мягкими, но не без последствий для работоспособности system-backup. Лучше сначала разобраться, зачем это вообще делать. Может, есть какая-то более конкретная проблема?
(Ответ для Leonid Krivoshein на комментарий #3) > (In reply to Антон Мидюков from comment #2) > > Наличие в образе определяется сборщиком образа. > Тут надо подумать, так как зависимости на самом деле нужные. Теоретически их > можно сделать более мягкими, но не без последствий для работоспособности > system-backup. Лучше сначала разобраться, зачем это вообще делать. Может, > есть какая-то более конкретная проблема? Для того, чтобы не включать в live файловую систему, которую не хочется. jfsutils или xfsprogs, например. В общем, непонятно, зачем зависимости у пакета, когда они есть в целевом образе. А если их там нет, то они и не нужны.
(In reply to Антон Мидюков from comment #4) > В общем, непонятно, зачем зависимости у пакета, когда они есть в целевом образе. > А если их там нет, то они и не нужны. Сохранение данных о файловой системе производится как бы снаружи целевой системы, когда эти разделы даже не смонтированы: https://git.altlinux.org/gears/s/system-backup.git?p=system-backup.git;a=blob;f=system-backup#l441 . Не стоит забываь, что на ALT Rescue должна быть пара system-backup и system-restore. Вторая не сможет воссоздать разметку без этих утилит. В общем, это как в случае с установщиком.
(Ответ для Leonid Krivoshein на комментарий #5) > (In reply to Антон Мидюков from comment #4) > > В общем, непонятно, зачем зависимости у пакета, когда они есть в целевом образе. > > А если их там нет, то они и не нужны. > Сохранение данных о файловой системе производится как бы снаружи целевой > системы, когда эти разделы даже не смонтированы: > https://git.altlinux.org/gears/s/system-backup.git?p=system-backup.git; > a=blob;f=system-backup#l441 . Не стоит забывать, что на ALT Rescue должна > быть пара system-backup и system-restore. Вторая не сможет воссоздать > разметку без этих утилит. В общем, это как в случае с установщиком. Сборщик Rescue определяет поддерживаемые файловые системы в нём. Что за system-restore?
(In reply to Антон Мидюков from comment #6) > Что за system-restore? То, что готовится в качестве ответной части "деплойной пары" ("разливалки"). Если мы систему чем-то забэкапили, нужно же её и чем-то восстановить из этих бэкапов. > Сборщик Rescue определяет поддерживаемые файловые системы в нём. Отсюда напрашивается решение (в качестве одного из вариантов) размещать эту "деплойную пару" на специализированном деплойном носителе и убрать из ALT Rescue.
(Ответ для Leonid Krivoshein на комментарий #7) > (In reply to Антон Мидюков from comment #6) > > Что за system-restore? > То, что готовится в качестве ответной части "деплойной пары" ("разливалки"). > Если мы систему чем-то забэкапили, нужно же её и чем-то восстановить из этих > бэкапов. > Это понятно. Непонятно откуда она возьмётся.
(In reply to Антон Мидюков from comment #8) > Это понятно. Непонятно откуда она возьмётся. Будет размещена в репозитории по мере готовности. Рабочий прототип годовалой давности есть тут: https://ftp.altlinux.org/pub/people/klark/deploy/example/ (можно даже в виртуалке проверить с загрузкой через iPXE-скрипт).
(Ответ для Leonid Krivoshein на комментарий #9) > (In reply to Антон Мидюков from comment #8) > > Это понятно. Непонятно откуда она возьмётся. > Будет размещена в репозитории по мере готовности. Рабочий прототип годовалой > давности есть тут: https://ftp.altlinux.org/pub/people/klark/deploy/example/ > (можно даже в виртуалке проверить с загрузкой через iPXE-скрипт). Я не о том. Вот как сейчас на deploy системе она берётся? Если мы исключим из Rescue system-backup, то как он на deploy системе появится, которая делается из этого Rescue?
(In reply to Антон Мидюков from comment #10) > Вот как сейчас на deploy системе она берётся? Поскольку её нет в репозитории, сейчас она просто рядышком лежит с бэкапами, а в данном примере скачивается с сервера отдельным архивом. Но это неправильно: она должна быть в образе ALT Rescue либо в специально подготовленном деплойном образе. > Если мы исключим из Rescue system-backup, то как он на deploy системе > появится, которая делается из этого Rescue? Никак. Нужно тогда собирать специальный деплойный rescue с system-backup и system-restore. Ещё вариант, как сейчас -- не использовать опакечивание, а запускать эти скрипты "на месте".
Не сказал сразу, что хотя более мягкие зависимости можно сделать, я почти уверен, что это превратит пару либо в частично нерабочее решение, либо отвественность за недостающие зависимости будет на сборщике образа. То есть, нет сомнений, что эти зависимости всё же более жёсткие, и отсутвие нужных тулзов на диске будет приводить к открытию всяких багов.
(Ответ для Leonid Krivoshein на комментарий #12) > Не сказал сразу, что хотя более мягкие зависимости можно сделать, я почти > уверен, что это превратит пару либо в частично нерабочее решение, либо > отвественность за недостающие зависимости будет на сборщике образа. То есть, > нет сомнений, что эти зависимости всё же более жёсткие, и отсутвие нужных > тулзов на диске будет приводить к открытию всяких багов. Ответственность должна лежать на сборщике образа.
