Re: [devel] I: usrmerge

[Leonid Krivoshein <klark.devel@gmail.com>]

On 6/3/24 01:02, Arseny Maslennikov wrote:
> On Mon, Jun 03, 2024 at 12:32:11AM +0300, Leonid Krivoshein wrote:
>> Доброго времени!
>>
>>
>> On 3/27/24 15:54, Arseny Maslennikov wrote:
>>> On Sat, Mar 16, 2024 at 04:24:44PM +0300, Arseny Maslennikov wrote:
>>>> On Sat, Feb 03, 2024 at 12:38:44AM +0300, Arseny Maslennikov wrote:
>>>>> === Сначала о пакетах ===
>>>>>
>>>>> Во-первых, не хотелось бы обновлять сотню пакетов в одной
>>>>> транзакции с пакетом filesystem, содержащим вместо /bin, /sbin,
>>>>> ... симлинки. Чтобы этого избежать, надо добиться, чтобы пакеты,
>>>>> кладущие что-либо в эти каталоги (вне %_prefix),
>>>>> устанавливались и на merged, и на unmerged, и на split[1].
>>>>> Для этого планируется ввести brp-модуль, который при сборке
>>>>> пакета, если в %buildroot лежит что-то в соотв. каталогах вне
>>>>> префикса, создаст копию этого файла в аналогичном месте под
>>>>> префиксом.
>>>>> Можно было бы вместо копии делать ссылку, но оказалось, что нет:
>>>>> * (упакованные в cpio) симлинк поверх файла или файл поверх симлинка нельзя
>>>>>     установить на merged-usr, т. е. поверх друг друга;
>>>>> * (упакованные в cpio) хардлинки нельзя установить на
>>>>>     split-usr-иерархию, потому что они придутся на разные ФС, и
>>>>>     rpm не сможет их расщепить (изготовить одинаковые inode).
>>>>> Это позволило снизить количество пакетов с файлами в /bin и
>>>>> /sbin, для которых потребуются ручные изменения, с 90 до ~20.
>>>>>
>>>>> [1] https://www.altlinux.org/Usrmerge#%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9
>>>> Почти реализовано (ждём install checks).
>>>> https://git.altlinux.org/tasks/327286
>>>> Можно коммитить задание, как только будет готово к коммиту и при
>>>> отсутствии иных возражений.
>>>>
>>>> Прошу одобрений от:
>>> Спасибо! Одобрения получены.
>>> Сегодня задание войдёт в репозиторий.
>>>
>> Прошу прощения за тупой вопрос, но я нигде не нашёл прямой рекомендации
>> использовать в качестве шебанга, например, /usr/bin/bash. Благодаря симлинку
>> ведь и старые шебанги будут корректно обрабатываться? Или не совсем так? А
>> что с зависимостями на /bin/bash?
> Работать скрипт будет одинаково вне зависимости от того, какой из двух
> путей написан в первой строке после #!.
>
> А вот с т. з. зависимостей в наших пакетах не всё равно, что туда
> писать. Что в скрипте написано, на то буквально и возникнет зависимость
> (по ссылке /bin и /sbin не проходит). В случае с sh и bash там обычно
> путь без %_prefix.

В этом месте я совсем запутался. (( Как правильно делать?

1. Оставлять старые шебанги с /bin или лучше менять их на /usr/bin?
2. Что из этого предпочтительно использовать в Requires: /bin/sh или 
/usr/bin/sh?
3. В Requires и в других видах зависимостей лучше не использовать макрос 
%_prefix?
4. Будут ли хоть как-то удовлетворяться зависимости по путям в /bin? 
Например, если в скрипте шебанг без /usr, а в спеке нет AutoReq: 
noshebang, будут ли корректно проставляться зависимости на /usr/bin/sh?

Отдельный интересный вопрос про скрипты, которые будут залетать в stage1 
с вероятно другой иерархией, но видимо не для этой рассылки.


> Встречались пакеты на autotools, в которых есть вызовы AC_CHECK_PROG или
> что-то подобное, которые ищут bash и находят его под /usr, а потом
> генерируется зависимость на /usr/bin/bash. Пока что мы такое исправляли
> установкой той переменной окружения, которая нужна (упоминается в
> ./configure, зависит от конкретного m4-макроса).
>
> Я бы предпочёл просто развешать `Provides:' с этими путями, конечно.

-- 
WBR, Leonid Krivoshein.