Bug 58070

Они используются для получения дополнительной информации при снятии бэкапа. Если их не будет в образе, бэкап будет либо не полным, либо его не получится сделать совсем. И то, и другое противоречит задаче программы. Можно исключить 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)
> Не сказал сразу, что хотя более мягкие зависимости можно сделать, я почти
> уверен, что это превратит пару либо в частично нерабочее решение, либо
> отвественность за недостающие зависимости будет на сборщике образа. То есть,
> нет сомнений, что эти зависимости всё же более жёсткие, и отсутвие нужных
> тулзов на диске будет приводить к открытию всяких багов.

Ответственность должна лежать на сборщике образа.