[devel] mismatched systemd.pc also present in p11 (was: [#348147] DONE (try 6) systemd.git=255.6-alt1 systemd-boot-trigger.git=1.1-alt1)

[Alexey Shabalin]

сб, 25 мая 2024 г., 03:40 Arseny Maslennikov <arseny на altlinux.org>:

> 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 <rider на basealt.ru>:
> > > >
> > > > 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(-)
>
> Обсудить надо сначала.
>

Не совсем понял тему письма. systemd.pc корректно matched с фактическими
путями.


> Я себе представлял нашу диспозицию следующим образом:
> * в p11 systemd 255+ у нас попадает, но %_unitdir и проч. всё ещё
>   назначены в /lib/systemd/system и проч., и cpio пакетов содержит эти
>   файлы вне %_prefix, другие интерфейсы к пакетам вроде
>   %_pkgconfigdir/systemd.pc тоже содержат пути вне %_prefix и патчатся
>   где-то в спеке systemd; сам systemd о старых путях не знает, как в
>   апстриме; приложения работают с теми путями, с которыми им сподручно;
>

Значит надо было рассказать о ваших планах кому-то еще. Или подготовить
задание с обновлением systemd самостоятельно. Я о ваших планах слышу
впервые. И несколько раз предупреждал что макросы в rpm надо будет
исправлять.

* в сизифе мы вскоре делаем именно то, что предлагает сейчас shaba@,
>   и вообще начинаем наконец выбрасывать отовсюду костыли для
>   искусственной поддержки unmerged-usr.
> Иными словами, в p10 сугубо filesystem < 3, в p11 filesystem > 3 и
>

От того, что unit или tmpfiles, или udev rules переезжают в /usr, работа
этих утилит никак не меняется, они и раньше поддерживали эти пути.
Выставлять для них требования к filesystem излишне.

переходная ситуация в пакетах, далее приводим пути в полное согласие.
> Именно такой у нас был уговор.
>
> А в четверг Алексей нам пакетом материализовал тезис "любишь медок —
> люби и холодок": давайте, мол, сразу в p11 как в сизифе.
>

Ну извините, я сам не ожидал, что systemd успеет проскочить до бранчевания
:)


> Мы в p11 не собирались идти этим путём по 2 причинам.
>

Э, не понял, почему в p11 не собирались идти этим путем? Весь usrmerge был
затеян ради этого.

1. вскоре (а лучше немедленно) после одобрения такого задания надо
>    пересобирать и коммитить около 333* пакетов-пользователей этих макросов,
>    а кого-то из них, возможно, изменять. Это 7 суток на репозиторий, т.
>    е. 14+ суток на два репозитория, будет только проходить через
>    сборочницу, не считая времени на фактическую подготовку сборочных
>    заданий и исследование, достаточно ли этого, чтобы всё исправить;
>

Не вижу проблем в починке пакетов. И проблем во времени и мощьностях тоже
не вижу.

2. пакеты, где эти файлы упакованы под /usr/$x, нельзя ставить
>    на unmerged-usr-иерархию, потому что в таких системах их программы не
>    найдут;


Можно. Найдут.
Изначально неправильные предположения приводят к неправильным выводам.

то есть, точечно обновлять такие пакеты, например, на p10 из
>    p11 в общем случае нельзя.


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

Строго говоря, в них следовало бы
>    Conflicts: filesystem < 3 указать (менять все спеки?).


Еще раз, изменение путей на /usr обычно не требует такого конфликта. Это
придуманная проблема.

Судя по
>    готовящемуся тексту https://altlinux.org/Update/p11, такое может
>    случиться даже в рамках рекомендуемой процедуры обновления, так что
>    такого класса багов лучше избежать.
>
> В общем, для p11, в отличие от сизифа, это точно недостаточная мера.
>

Я не спорю, что проблемы надо будет решать в сизифе, и сразу отправлять
решения в p11.


>
----------- следующая часть -----------
Вложение в формате HTML было удалено...
URL: <http://lists.altlinux.org/pipermail/devel/attachments/20240525/3fb1a7fb/attachment-0001.html>