Re: [devel] RemovePathPostfixes

[Alexey Shabalin <a.shabalin@gmail.com>]

пт, 5 февр. 2021 г. в 05:51, Dmitry V. Levin <ldv@altlinux.org>:
>
> On Fri, Feb 05, 2021 at 04:31:50AM +0300, Alexey Shabalin wrote:
> [...]
> > А RemovePathPostfixes позволяет по одному пути упаковать разные файлы
> > в разные бинарные rpm из одного src.rpm пакета.
> > Да конфликтующие, но разные и из одного src.rpm.
> > Я не думаю, что появится еще какая-нибудь реализация systemd-tmpfiles
> > (разве что найдется герой и напишет её на shell).
> > Поэтому тут альтернативы лишние, а конфликт в самый раз.
>
> Допустим, в репозитории есть несколько конфликтующих провайдеров
> /sbin/systemd-tmpfiles, и допустим, что в некотором пакете есть
> зависимость на /sbin/systemd-tmpfiles, возможно, даже автоматически
> вычисленная.
>
> Какого из провайдеров должен установить apt-get, если ни одного из
> провайдеров не установлено?

Если мы говорим об обыкновенной системе, то этот провайдер обычно уже
существует в системе,
для systemd это пакет systemd-utils, для sysv должен быть systemd-*-standalone.

> Того, который указан в
> /etc/apt/pkgpriorities?  Значит, для каждого дистрибутива будет свой
> /etc/apt/pkgpriorities, очень удобно.  А какого провайдера указать в
> /etc/apt/pkgpriorities, используемом для сборки пакетов в репозиторий?
> А почему именно его?

Мне кажется apt в состоянии вычислить предпочтительный пакет без
дополнительных указаний.
А какая разница для сборочницы какой провайдер приедет? они оба должны
работать одинаково.

> Альтернативные провайдеры в Сизифе есть, но это PITA.
>
> RemovePathPostfixes просто позволит причинять эту боль быстрее,
> чем мы будем успевать её купировать.
>
> Я не против RemovePathPostfixes, если каждый альтернативный провайдер
> будет проходить обязательную процедуру согласования, на которой
> релиз-инженеры всех дистрибутивов и операторы всех сборочниц будут давать
> отмашку, когда у них будет всё готово к появлению нового альтернативного
> провайдера.
>
> На самом деле, такая процедура нам давно была нужна и без всяких
> RemovePathPostfixes.  Тогда, например, не возникло бы проблемы с
> неожиданным появлением неподходящего провайдера network-config-subsystem.


-- 
Alexey Shabalin