Bug 49860

Задача ждёт патчей от заинтересованных.
Обратите внимание, что в скриптах xfsprogs есть запуск systemctl и задачу нужно решать через апстрим.

(In reply to Anton Farygin from comment #1)
> Задача ждёт патчей от заинтересованных.
> Обратите внимание, что в скриптах xfsprogs есть запуск systemctl и задачу
> нужно решать через апстрим.

xfs_scrub_all умеет работать как с systemd, так и без.

xfs_scrub_fail -- это, по сути, часть systemd'шной обвязки вокруг xfs_scrub, и на системах без systemd не используется.

Других упоминаний systemctl я не вижу, так что апстрима всё нормально написано и без systemd должно работать. Или я что-то упускаю?

да, надо ещё поправить способ детекта использования systemd

А почему не вынести в отдельный подпакет xfsprogs-xfs_scrub? В Fedora это отдельный подпакет с таким вот описанием:
xfsprogs-xfs_scrub - XFS filesystem online scrubbing utilities
xfs_scrub attempts to check and repair all metadata in a mounted XFS filesystem.
WARNING!  This program is EXPERIMENTAL, which means that its behavior and
interface could change at any time!

Вашей задачи это не решает, а когда-то оно выйдет из экспериментального состояния.

(Ответ для Anton Farygin на комментарий #5)
> Вашей задачи это не решает, а когда-то оно выйдет из экспериментального
> состояния.

Как это не решает? В него выносятся:
/usr/lib64/xfsprogs/xfs_scrub_fail
/usr/sbin/xfs_scrub
/usr/sbin/xfs_scrub_all
/usr/share/xfsprogs/xfs_scrub_all.cron
/usr/share/man/man8/xfs_scrub.8.xz
/usr/share/man/man8/xfs_scrub_all.8.xz
/lib/systemd/system/xfs_scrub@.service
/lib/systemd/system/xfs_scrub_all.service
/lib/systemd/system/xfs_scrub_all.timer
/lib/systemd/system/xfs_scrub_fail@.service

А остальному systemd не требуется.
Зачем это всем по дефолту ставить? Кому надо установит или включит в базовую поставку дистрибутива.

Не решает, т.к. зависимость у scrub от systemd не исчезает, а просто прячется.

Нужно решить нормально.

(Ответ для Anton Farygin на комментарий #7)
> Не решает, т.к. зависимость у scrub от systemd не исчезает, а просто
> прячется.

Никуда зависимость на systemd у scrub не прячется. А xfsprogs не будет по объективным причинам зависеть от systemd.
Систему на sysvinit без xfsprogs эксплуатировать практически невозможно, так как  от xfsprogs зависят lvm, udisks2.

> 
> Нужно решить нормально.

Нормальное решение - локализовать проблему, чтобы тот, кому нужен scrub на sysvinit, чинил xfsprogs-xfs_scrub. А так, получается, scrub никому не нужен на sysvinit, но sysvinit использовать из-за него нельзя.

всё верно - тот, кому нужен xfsprogs на sysvinit должен поддерживать xfsprogs на sysvinit в полном объёме.

(Ответ для Anton Farygin на комментарий #9)
> всё верно - тот, кому нужен xfsprogs на sysvinit должен поддерживать
> xfsprogs на sysvinit в полном объёме.
На сейчас это регрессия в пакете, приводящая к слому важной сборки (помнится по статистике -- одной из самых популярных на то время, когда я их сопровождал, в терминах количества загрузок).

Так не годится -- ломать пакет в одни ворота, а затем требовать чинить через апстрим.
Давай отпилим в подпакет -- и когда мне или ещё кому понадобится xfs_scrub на sysvinit, тогда и будем чинить.

Нет, это плохое предложение. Никакой регрессии в новом функционале нет - идёт дальнейшее улучшение функционала и пакет добавляет больше зависимостей на systemd. В целом движение понятное и спорить с ним тяжело.

(In reply to Anton Farygin from comment #3)
> да, надо ещё поправить способ детекта использования systemd

А что с ним не так? Если в системе нет systemd-escape, path_to_serviceunit вернёт None, и xfs_scrub будет запущен "непосредственно". Всё прекрасно и должно работать.

Предлагаю тем, у кого есть системы с xfs и без systemd протестировать xfs_scrub_all в таких условиях и тем самым доказать, что зависимость лишняя.

(Ответ для Anton Farygin на комментарий #11)
> Нет, это плохое предложение. Никакой регрессии в новом функционале нет -
> идёт дальнейшее улучшение функционала и пакет добавляет больше зависимостей
> на systemd. В целом движение понятное и спорить с ним тяжело.

А функционал то вообще проверялся? У наших ядер:
# CONFIG_XFS_ONLINE_SCRUB is not set

Без этого же работать не будет. Выдаёт:
Error: <mountpoint>: Kernel metadata scrubbing facility is not available.

  Теперь из-за этой зависимости linstor не собирается (linstor-satellite
  не может пройти install check):

	x86_64: linstor-satellite=1.27.0-alt1 install failed:
 Reading Package Lists...
 Building Dependency Tree...
 MI2a: marked for install (shallow): linstor-satellite
 MI2a:  satisfying Depends: lvm2  (NULL)
 MI2a:   maybe install (a direct target): lvm2 2.03.22-alt1:sisyphus+328928.400.3.1@1694103931
 MI2a:  target SELECTED: lvm2 2.03.22-alt1:sisyphus+328928.400.3.1@1694103931
 MI2a:  requesting to install lvm2 (unspec'd ver; inspect with Debug::pkgMark-shallow)
 MI2a:    marked for install (shallow): lvm2
 MI2a:     satisfying Depends: xfsprogs  (NULL)
 MI2a:      maybe install (a direct target): xfsprogs 6.6.0-alt1:sisyphus+344035.100.1.1@1711788966
 MI2a:     target SELECTED: xfsprogs 6.6.0-alt1:sisyphus+344035.100.1.1@1711788966
 MI2a:     requesting to install xfsprogs (unspec'd ver; inspect with Debug::pkgMark-shallow)
 MI2a:       marked for install (shallow): xfsprogs
 MI2a:        satisfying Depends: systemd  (NULL)
 MI2a:         maybe install (a direct target): systemd 1:254.10-alt1:sisyphus+343748.100.3.1@1711611773
 MI2a:        target SELECTED: systemd 1:254.10-alt1:sisyphus+343748.100.3.1@1711611773
 MI2a:        requesting to install systemd (unspec'd ver; inspect with Debug::pkgMark-shallow)
 MI2a:          marked for install (shallow): systemd
 MI2a:           satisfying Depends: libnss-systemd = 1:254.10-alt1:sisyphus+343748.100.3.1
 MI2a:            maybe install (a direct target): libnss-systemd 1:254.10-alt1:sisyphus+343748.100.3.1@1711611773
 MI2a:           target SELECTED: libnss-systemd 1:254.10-alt1:sisyphus+343748.100.3.1@1711611773
 MI2a:           requesting to install libnss-systemd (unspec'd ver; inspect with Debug::pkgMark-shallow)
 MI2a:             marked for install (shallow): libnss-systemd
 MI2a:  satisfying Depends: drbd-utils >= 9.7.0
 MI2a:   maybe install (a direct target): drbd-utils 9.27.0-alt1:sisyphus+337046.100.1.1@1703272112
 MI2a:  target SELECTED: drbd-utils 9.27.0-alt1:sisyphus+337046.100.1.1@1703272112
 MI2a:  requesting to install drbd-utils (unspec'd ver; inspect with Debug::pkgMark-shallow)
 MI2a:    marked for install (shallow): drbd-utils
 Starting
 Starting 2
 Investigating sysvinit 3.00-alt2:sisyphus+300218.200.2.1@1652976073
  Package sysvinit has a broken Conflicts: systemd  (NULL)
   Considering systemd 1 as a solution to sysvinit 0
     Reinst not done for non-upgradable sysvinit
   Removing sysvinit rather than change one of its deps: perhaps systemd or another one
 Investigating drbd-utils 9.27.0-alt1:sisyphus+337046.100.1.1@1703272112
  Package drbd-utils has a broken Depends: /sbin/reboot  (NULL)
   Considering systemd-sysvinit 0 as a solution to drbd-utils 2
     Re-Instated systemd-sysvinit
   Installing systemd-sysvinit
 Done
 Selected version linstor-satellite#1.27.0-alt1:sisyphus+344420.300.1.1@1712247338 for linstor-satellite=1.27.0-alt1
 The following extra packages will be installed:
   drbd-utils libnss-systemd linstor-satellite lvm2 systemd systemd-sysvinit
   xfsprogs
 The following packages will be REMOVED:
   sysvinit
 The following NEW packages will be installed:
   drbd-utils libnss-systemd linstor-satellite lvm2 systemd systemd-sysvinit
   xfsprogs
 0 upgraded, 7 newly installed, 1 removed and 0 not upgraded.
 Need to get 0B/9284kB of archives.
 After unpacking 27.7MB of additional disk space will be used.
 Executing RPM (hsh-rpmi-print-files -e -r /tmp/hasher/aptbox --nodeps)...
 hsh-rpmi-print-files: cannot erase packages: sysvinit.x86_64
 Executing RPM (hsh-rpmi-print-files -U -v -h -r /tmp/hasher/aptbox --oldpackage)...
 /home/bee01/gb-repo/x86_64/RPMS.classic/systemd-254.10-alt1.x86_64.rpm
 /home/bee01/gb-repo/x86_64/RPMS.classic/libnss-systemd-254.10-alt1.x86_64.rpm
 /home/bee01/gb-repo/noarch/RPMS.classic/systemd-sysvinit-254.10-alt1.noarch.rpm
 /home/bee01/gb-repo/x86_64/RPMS.classic/xfsprogs-6.6.0-alt1.x86_64.rpm
 /home/bee01/gb-repo/x86_64/RPMS.classic/lvm2-2.03.22-alt1.x86_64.rpm
 /home/bee01/gb-repo/x86_64/RPMS.classic/drbd-utils-9.27.0-alt1.x86_64.rpm
 /home/bee01/gb-repo/noarch/RPMS.classic/linstor-satellite-1.27.0-alt1.noarch.rpm
 Done.
 E: Sub-process hsh-rpmi-print-files returned an error code (1)
 hsh-install: Failed to calculate package file list.
 hsh-install: Failed to generate package file list.
2024-Apr-04 16:22:27 :: [x86_64] #300 linstor-satellite: install check FAILED

Для начала предлагаю собирать пакет с --disable-scrub, чтобы вообще не собирать и не паковать нерабочий код.

Даже в Федоре, в которой, мягко говоря, не очень любят распиливать пакеты на части, это экспериментальное хозяйство упаковано в отдельный подпакет xfsprogs-xfs_scrub.

В обосновании написано:
In Fedora CoreOS we are trying to not have Python dependencies in base host. We make use of utility like xfs_growfs from xfsprogs. It will be nice if we can get Python dependent utility in a sub-package. This will help to not pull in Python dependencies where xfs_scrub_all is not required.

https://bugzilla.redhat.com/show_bug.cgi?id=1666839

xfsprogs-6.6.0-alt2 -> sisyphus:

 Tue Apr 02 2024 Anton Midyukov <antohami@altlinux> 6.6.0-alt2
 - NMU: xfs_scrub_fail.in: hide systemctl, systemd-escape program in variables
   (Closes: 49860)

(Ответ для Repository Robot на комментарий #17)
> xfsprogs-6.6.0-alt2 -> sisyphus:
> 
>  Tue Apr 02 2024 Anton Midyukov <antohami@altlinux> 6.6.0-alt2
>  - NMU: xfs_scrub_fail.in: hide systemctl, systemd-escape program in
> variables
>    (Closes: 49860)

Антон, спасибо!