On Fri, May 24, 2024 at 07:49:49PM +0300, Yuri Sedunov wrote: > В Пт, 24/05/2024 в 16:53 +0300, Alexey Shabalin пишет: > > пт, 24 мая 2024 г. в 13:57, Anton Farygin : > > > > > > On 24.05.2024 11:52, Dmitry V. Levin wrote: > > > > On Thu, May 23, 2024 at 11:51:13AM +0000, Girar pender (shaba) > > > > wrote: > > > > > https://git.altlinux.org/tasks/archive/done/_339/348147/logs/events.6.3.log > > > > > 2024-May-23 11:09:14 :: task #348147 for sisyphus resumed by > > > > > shaba: > > > > > #100 removed > > > > > #140 build 255.6-alt1 from /people/shaba/packages/systemd.git > > > > > fetched at 2024-May-23 07:42:21 > > > > После того, как этот пакет попал в Сизиф, Он ещё и в p11 попал, до форка. Из этого следует, что... > > > > сломалась сборка около сотни > > > > пакетов, в которых есть файлы для systemd или udev ...ещё и в этом репозитории. > > > > > > > Да, я тоже заметил. > > > > > > Надеюсь исправление тоже надо делать только в одном месте. > > > > Этого следовало ожидать. Значения в pkgconfig(systemd) изменились, > > эти пакеты заглядывают в него чтобы узнать куда устанавливать файлы. > > В задании #349068 > > id=349068 locked=no shared=no fail_early=yes test_only=no repo=sisyphus > owner=shaba state=EPERM > > И чего это никто не спешит одобрить и запустить это задание? Да понятно, чего: > > --- > > platform.in | 40 +++++++++++++++++++++------------------- > > 1 files changed, 21 insertions(+), 19 deletions(-) Обсудить надо сначала. Я себе представлял нашу диспозицию следующим образом: * в p11 systemd 255+ у нас попадает, но %_unitdir и проч. всё ещё назначены в /lib/systemd/system и проч., и cpio пакетов содержит эти файлы вне %_prefix, другие интерфейсы к пакетам вроде %_pkgconfigdir/systemd.pc тоже содержат пути вне %_prefix и патчатся где-то в спеке systemd; сам systemd о старых путях не знает, как в апстриме; приложения работают с теми путями, с которыми им сподручно; * в сизифе мы вскоре делаем именно то, что предлагает сейчас shaba@, и вообще начинаем наконец выбрасывать отовсюду костыли для искусственной поддержки unmerged-usr. Иными словами, в p10 сугубо filesystem < 3, в p11 filesystem > 3 и переходная ситуация в пакетах, далее приводим пути в полное согласие. Именно такой у нас был уговор. А в четверг Алексей нам пакетом материализовал тезис "любишь медок — люби и холодок": давайте, мол, сразу в p11 как в сизифе. Мы в p11 не собирались идти этим путём по 2 причинам. 1. вскоре (а лучше немедленно) после одобрения такого задания надо пересобирать и коммитить около 333* пакетов-пользователей этих макросов, а кого-то из них, возможно, изменять. Это 7 суток на репозиторий, т. е. 14+ суток на два репозитория, будет только проходить через сборочницу, не считая времени на фактическую подготовку сборочных заданий и исследование, достаточно ли этого, чтобы всё исправить; 2. пакеты, где эти файлы упакованы под /usr/$x, нельзя ставить на unmerged-usr-иерархию, потому что в таких системах их программы не найдут; то есть, точечно обновлять такие пакеты, например, на p10 из p11 в общем случае нельзя. Строго говоря, в них следовало бы Conflicts: filesystem < 3 указать (менять все спеки?). Судя по готовящемуся тексту https://altlinux.org/Update/p11, такое может случиться даже в рамках рекомендуемой процедуры обновления, так что такого класса багов лучше избежать. В общем, для p11, в отличие от сизифа, это точно недостаточная мера. ____ * https://www.altlinux.org/Usrmerge#MigrateDirMacros