Да, теперь для корректной работы xfs нужен systemd в части scrubbing.

А зачм обновлять systemd ?

И это не ошибка.

(In reply to Anton Farygin from comment #1)
> Да, теперь для корректной работы xfs нужен systemd в части scrubbing.

А давай-ка поподробнее, а?

Потому что в меня в Gentoo xfsprogs-5.6.0 прекрасно собирается и работает в системе, где systemd вообще нет, даже в виде libsystemd на диске.

Собрать его можно, и вероятно он даже будет работать, но в данном случае я не будут отрывать от него поддержку systemd, т.к. пострадают все пользователи дистрибутивов, выпущенных с поддержкой systemd.

Соберите себе локально, если вас беспокоит наличие systemd

Добавлю, что зависимость на systemd-utils сгенерилась автоматически, и, возможно, тут виноват скрипт /lib64/xfsprogs/xfs_scrub_fail

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

(Ответ для Anton Farygin на комментарий #1)
> Да, теперь для корректной работы xfs нужен systemd в части scrubbing.
Антон, пожалуйста, не надо дезинформировать коллег.  Один редхат уже есть.

$ rpmpeek Sisyphus/files/x86_64/RPMS/xfsprogs-5.6.0-alt1.x86_64.rpm grep -Frsl xfs_scrub_fail .
./lib/systemd/system/xfs_scrub_fail@.service
./lib/systemd/system/xfs_scrub@.service

Другими словами, скрипт /lib64/xfsprogs/xfs_scrub_fail нужен для сервисов systemd, а не наоборот.

(In reply to Dmitry V. Levin from comment #7)
> $ rpmpeek Sisyphus/files/x86_64/RPMS/xfsprogs-5.6.0-alt1.x86_64.rpm grep
> -Frsl xfs_scrub_fail .
> ./lib/systemd/system/xfs_scrub_fail@.service
> ./lib/systemd/system/xfs_scrub@.service
> 
> Другими словами, скрипт /lib64/xfsprogs/xfs_scrub_fail нужен для сервисов
> systemd, а не наоборот.

В скрипте systemd нужен только для получения лога перед отправкой письма об ошибке:
systemctl status --full --lines 4294967295 "xfs_scrub@${mntpoint}") | "${mailer}" -t -i

Это можно обойти многими способами.

(In reply to Andrew Savchenko from comment #8)
> (In reply to Dmitry V. Levin from comment #7)
> > $ rpmpeek Sisyphus/files/x86_64/RPMS/xfsprogs-5.6.0-alt1.x86_64.rpm grep
> > -Frsl xfs_scrub_fail .
> > ./lib/systemd/system/xfs_scrub_fail@.service
> > ./lib/systemd/system/xfs_scrub@.service
> > 
> > Другими словами, скрипт /lib64/xfsprogs/xfs_scrub_fail нужен для сервисов
> > systemd, а не наоборот.
> 
> В скрипте systemd нужен только для получения лога перед отправкой письма об
> ошибке:
> systemctl status --full --lines 4294967295 "xfs_scrub@${mntpoint}") |
> "${mailer}" -t -i
> 
> Это можно обойти многими способами.

Зависимость нужно погасить, конечно, но зачем это нужно обходить?

$ rpmpeek Sisyphus/files/x86_64/RPMS/xfsprogs-5.6.0-alt1.x86_64.rpm head -3 ./lib64/xfsprogs/xfs_scrub_fail
#!/bin/bash

# Email logs of failed xfs_scrub unit runs

Скрипт написан для использования юнитами systemd, поэтому использование в нём средств systemd вполне логично.

(In reply to Dmitry V. Levin from comment #9)
> (In reply to Andrew Savchenko from comment #8)
> > (In reply to Dmitry V. Levin from comment #7)
> > > $ rpmpeek Sisyphus/files/x86_64/RPMS/xfsprogs-5.6.0-alt1.x86_64.rpm grep
> > > -Frsl xfs_scrub_fail .
> > > ./lib/systemd/system/xfs_scrub_fail@.service
> > > ./lib/systemd/system/xfs_scrub@.service
> > > 
> > > Другими словами, скрипт /lib64/xfsprogs/xfs_scrub_fail нужен для сервисов
> > > systemd, а не наоборот.
> > 
> > В скрипте systemd нужен только для получения лога перед отправкой письма об
> > ошибке:
> > systemctl status --full --lines 4294967295 "xfs_scrub@${mntpoint}") |
> > "${mailer}" -t -i
> > 
> > Это можно обойти многими способами.
> 
> Зависимость нужно погасить, конечно, но зачем это нужно обходить?
> 
> $ rpmpeek Sisyphus/files/x86_64/RPMS/xfsprogs-5.6.0-alt1.x86_64.rpm head -3
> ./lib64/xfsprogs/xfs_scrub_fail
> #!/bin/bash
> 
> # Email logs of failed xfs_scrub unit runs
> 
> Скрипт написан для использования юнитами systemd, поэтому использование в
> нём средств systemd вполне логично.

Тогда что предлагается сделать? Вынести в отдельный пакет?

(Ответ для Dmitry V. Levin на комментарий #7)
> $ rpmpeek Sisyphus/files/x86_64/RPMS/xfsprogs-5.6.0-alt1.x86_64.rpm grep
> -Frsl xfs_scrub_fail .
> ./lib/systemd/system/xfs_scrub_fail@.service
> ./lib/systemd/system/xfs_scrub@.service
> 
> Другими словами, скрипт /lib64/xfsprogs/xfs_scrub_fail нужен для сервисов
> systemd, а не наоборот.

помимо xfs_scrub_fail есть ещё xfs_scrub_all - написанный на python скрипт, который тоже заточен на работу в конфигурации с systemd.

Тем, кто будет пытаться отовать от xfsprogs работу с systemd стоит проверить и xfs_scrub_all - судя по коду он может работать, но некоторые моменты вызывают сомнения.

У меня стендов на sysvinit не осталось и их появление не ожидается.

Что касается зависимости, то её я погасить могу в следующей сборке.

xfsprogs-5.7.0-alt1 -> sisyphus:

 Wed Aug 05 2020 Anton Farygin <rider@altlinux.ru> 5.7.0-alt1
 - 5.7.0
 - hid dependency on systemd-utils (closes: #38712)

Спасибо!

Добрый день!

Проблема снова вылезла:

 # apt-get install xfsprogs
Reading Package Lists... Done
Building Dependency Tree... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.

Since you only requested a single operation it is extremely likely that
the package is simply not installable and a bug report against
that package should be filed.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
  xfsprogs: Depends: systemd
E: Broken packages

xfsprogs-6.6.0-alt1

пожалуйста, открывайте новые ошибки а не переоткрывайте старые исправленные.