[devel] possible incompatibilities

[Arseny Maslennikov]

On Sun, Feb 04, 2024 at 05:45:23PM +0700, Антон Мидюков wrote:
> 04.02.2024 17:30, Arseny Maslennikov пишет:
> > On Sun, Feb 04, 2024 at 02:46:44PM +0700, Антон Мидюков wrote:
> >> Почему самостоятельный переезд пакетов в /usr/ может сломать в будущем переезд на usr-merge?
> > 
> > Тут надо прояснить смыслы слов.
> > 
> > Я так понял, что переезд — это наивный перенос; взять и упаковать в
> > другое место, из старого убрать. Такой наивный перенос файлов ломает не
> > будущее, а обновление с прошлого.
> 
> Да, я про такой перенос. Но перенос уже после того, как filesystem в репозитории обновлён.
> Разумеется, я не про то, чтобы собирать в p10 такие пакеты. А только в p11 и Сизиф.
> 
> > 
> > Вот гипотетический пример: если в соотв. пакетах, например, coreutils
> > или util-linux, просто взять и убрать все файлы вне префикса,
> > перенеся, например, /sbin/mount в /usr/sbin/mount, то:
> > - на системах со split-usr при загрузке до появления /usr файл
> >   /bin/mount будет отсутствовать;
> 
> При обновления /usr уже примонтирован.
> 
> > - такой пакет перестанет удовлетворять Requires: /sbin/mount.
> 
> Так он не соберётся в репозиторий, если не будет удовлетворять зависимостям.

Вот именно. Для ряда пакетов такие зависимости существуют, то есть их
файлы сейчас просто нельзя наивно переложить и собрать в репозиторий;
нужно формировать пакет так, чтобы он ставился на все иерархии, хотя бы
для того, чтобы он смог установиться в хешерницу на сборочнице, где
собирают другие пакеты.
Есть такой милый, бесполезный пакет lsb-core, который из таких
зависимостей в существенной степени и состоит.

Более того, в пакетах бывают post-скрипты; они пользуются программами
из /bin и /sbin, а те — библиотеками из /%_lib. Если на момент запуска
post-скрипта иерархия ещё не переведена, а пакет с программой уже
обновился и перенёс файл под префикс, то по старому пути он будет
недоступен; если его запускают без учёта PATH — процесс оборвётся.

> > Или, если речь идёт о sh и awk каких-нибудь, они часто указаны в
> > сценариях в качестве интерпретаторов: "#!/bin/awk". Файл по этому пути
> > должен быть.
> 
> Так после обновления всё уже будет.
> 
> Я не понимаю, почему мы не можем сразу же после обновления filesystem начать перенос в спеках в /usr по мере обновления пакетов, которые не планируется собирать в p10.
> Почему мы должны ждать p12?

Потому что тогда filesystem должен будет обновиться строго до того, как
эти пакеты установятся в систему, т. е. надо будет мимо rpm переносить
файлы под префикс в том виде, в котором они будут в старой системе (p10
или Sisyphus от древней даты).

В случае, если мы это делаем до обновления или перед распаковкой нового
filesystem, у нас нет способа доказать, что это возможно автоматически
сделать для ∀ возможных множеств установленных пакетов. Я задумываюсь
над тем, чтобы, если обнаруживаются неисправимые конфликты, не
игнорировать их, как сейчас, а завершаться со статусом != 0, и запускать
это в %pretrans; тогда, по идее, апгрейд тоже завершится с ошибкой до
того, как будут затронуты какие-то файлы.
(Неисправимый конфликт — это, например, /bin/ex -> vi и /usr/bin/ex ->
vim; не очевидно, какой из них стоит оставить, а какой убрать. Тут нужно
менять пакет vim. А при обновлении надо будет сначала поставить
исправленную версию, а потом повторять апгрейд.)

> почему мы не можем... начать перенос в спеках.
> почему мы должны ждать p12?
Если коротко, то:
* если получится совершать миграцию в posttrans — можем;
* если мигрировать в pretrans и заранее отказываться трогать что-либо
  при неисправимых конфликтах — тоже можем;
иначе лучше не надо.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : signature.asc
Тип     : application/pgp-signature
Размер  : 833 байтов
Описание: отсутствует
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20240204/c69701a9/attachment-0001.bin>