[devel] possible incompatibilities

[Антон Мидюков]

04.02.2024 19:20, 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 от древней даты).

То есть при обновлении с бранча p10 до p11 установка filesystem перед dist-upgrade должно решить проблему?
Если так, то это можно прописать в инструкции обновления p10 -> p11.


> 
> В случае, если мы это делаем до обновления или перед распаковкой нового
> filesystem, у нас нет способа доказать, что это возможно автоматически
> сделать для ∀ возможных множеств установленных пакетов. Я задумываюсь
> над тем, чтобы, если обнаруживаются неисправимые конфликты, не
> игнорировать их, как сейчас, а завершаться со статусом != 0, и запускать
> это в %pretrans; тогда, по идее, апгрейд тоже завершится с ошибкой до
> того, как будут затронуты какие-то файлы.
> (Неисправимый конфликт — это, например, /bin/ex -> vi и /usr/bin/ex ->
> vim; не очевидно, какой из них стоит оставить, а какой убрать. Тут нужно
> менять пакет vim. А при обновлении надо будет сначала поставить
> исправленную версию, а потом повторять апгрейд.)
> 
>> почему мы не можем... начать перенос в спеках.
>> почему мы должны ждать p12?
> Если коротко, то:
> * если получится совершать миграцию в posttrans — можем;
> * если мигрировать в pretrans и заранее отказываться трогать что-либо
>   при неисправимых конфликтах — тоже можем;
> иначе лучше не надо.
> 
> 
> _______________________________________________
> Devel mailing list
> Devel на lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

-- 
С уважением, Антон Мидюков <antohami на altlinux.org>