У xfsprogs 6.6.0-alt1 появилась зависимость на systemd. Из-за этого невозможно собрать regular-rescue. Прошу отфильтровать зависимость на systemd.
Задача ждёт патчей от заинтересованных. Обратите внимание, что в скриптах 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) Антон, спасибо!
