[devel] I: usrmerge

[Arseny Maslennikov]

On Sat, Feb 03, 2024 at 10:46:42AM +0300, Anton Farygin wrote:
> On 03.02.2024 00:38, Arseny Maslennikov wrote:
> > Предыдущее обсуждение — в треде:
> > https://lore.altlinux.org/devel/ZKQaFPEN0qnNWGnz@cello/
> 
> 
> У меня основной вопрос - сломаю ли я что-то, если уже сейчас начну в своих
> пакетах переделывать на %_prefix

Нет, если сделаете всё правильно. :)

Надо обеспечить, чтобы пакет ставился и на merged-, и на unmerged-. Если
мейнтейнеры хотели бы сами, руками, поправить соотв. образом свои пакеты,
ничего страшного в этом не будет. Для этого надо, как описано в предыдущем
письме, создавать в %buildroot копии и указать их в %files (где они уже
указаны, скорее всего).

> (кое-где я так уже сделал и этого вроде
> никто не заметил( ?

btrfs-progs уже сегодня не устанавливается на split-usr-конфигурацию,
да, потому что там жёсткие ссылки. Впрочем, багу по этому поводу до сей
поры действительно никто ещё не создал! =)

Но я тем не менее убеждён, что не стоит считать, что split-usr ни у кого
нет; иначе после начала массового перехода пакетов появятся и жалобы —
громкие и агрессивные, с угрозами жизни и здоровью. Очень вероятно, что
те, кто ставил так систему, просто не любят btrfs.

> Ну и второй - не пора ли плавно добавить в make-initrd поддержку нового
> расположения для /lib/firmware и /lib/modules, плавно на уровне пакетов
> сделав нужную миграцию, поддерживающую обновления ?

В merged-usr иерархии будет симлинк /lib -> usr/lib.
Нужные файлы будут доступны и по новому, и по старому расположению; не
вижу пока смысла что-то здесь предпринимать, как и явно упаковывать
/lib/firmware и /lib/modules в firmware-linux и ядрах под префикс.
Если изменить там путь, то такие пакеты перестанут поддерживать
unmerged-usr совсем. Это стоит делать не сразу.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : signature.asc
Тип     : application/pgp-signature
Размер  : 833 байтов
Описание: отсутствует
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20240203/793ee4ce/attachment.bin>