Usrmerge/FurtherOptions

Заранее приношу извинения, набирал текст второпях; надеюсь, не допустил фактических ошибок. -- arseny@

Статус

Сейчас у нас в пакете usrmerge есть скрипт, способный аккуратно перенести файлы и каталоги из unmerged-legacy-каталогов под /usr. Возможно, в нём потребуется переработать обработку уже существующих симлинков не вида /$x/$y <-> /usr/$x/$y. Симлинки указанного вида он восстанавливать умеет; в коде они обнаруживаются, и для них запрограммировано явное действие.

Требует дискуссии

В процессе подготовки базовой сборочной среды, в которой /bin, /sbin и /lib* являются симлинками внутрь /usr, обнаружилось, что:

• пакеты имеют зависимости на файлы в этих каталогах, например, Requires: /bin/awk;
• пути в /bin и проч. прописываются в hashbang генерируемых скриптов, и это не только /bin/sh;

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

Пакеты можно разбить на категории сложности:

1. Те, что ничего не кладут в / и не требуют изменений.
2. Те, что помещают файлы или симлинки в /bin, /sbin. Сейчас это делается при помощи кода в спеках; было бы желательно автоматизировать такое размещение на обеих hier, что и предлагается обсудить.
3. Те, что помещают файлы в /lib/*. Они либо не требуют прямых изменений (потому что кладут файлы в каталог под макросом, например, %_tmpfilesdir, либо к каталогу, с которым они работают, нужно приписать /usr.

Можно выделить два тактических направления движения вперёд:

1. Запатчить rpm, чтобы тот при установке/обновлении/удалении пакетов определял, будет ли установлен, обновлён или удалён файл вида /usr/$d/$x, и в этом случае проводил аналогичное действие с /$d/$x, если это необходимо (автор идеи: legion@)
2. Попытаться соорудить вспомогательную логику на макросах, и включить её в состав rpm-build. В репозиториях без поддержки unmerged-usr эти макросы будут раскрываться в то, что нужно включить в %install, %files, %post (автор идеи: iv@; я пока считаю, что мы не потянем ручные правки такого масштаба в спеках)

Доводы в поддержку патчить RPM

• Патч накладывается в одном месте и решает подзадачу целиком.
  • Соответственно, ему легко довольно быстро пройти через сборочницу.

Доводы против патчить RPM

• Ваня утверждает, что генерируемые симлинки не будут никому принадлежать в смысле rpmdb или даже apt, и это невозможно изменить.

Доводы в поддержку патчить секции спеков

• Не нужно вникать в то, как RPM устанавливает файлы.
• Ваня счёл, что пакетов, где нужно будет это сделать, немного: лишь те, которые удовлетворяют зависимостям на unmerged-usr-пути, и из их %install-секции и так придётся убирать код, перекладывающий файлы в /bin, etc. Этим путём пошли SuSE, но у них можно глобально на уровне сборочницы переключать ряд макросов.
  • glebfm@ заявил, что мы можем почти так же: нам ничто не мешает переключать макросы в пакете rpm-build, разве что таким изменениям тоже нужно будет быть собранными в виде заданий и пройти все проверки.

Доводы против патчить секции спеков

• Не все из участников обсуждения уверены, что %post-скрипты, создающие файл в /bin, смогут правильно создать /bin/sh при установке пакета, его содержащего (может быть, в этом случае просто нужна особая логика).
• Около 400 пакетов потребуется не просто исправить, но и пропустить через сборочницу. Существенную их часть будет желательно собрать либо в одной транзакции, либо хотя бы между публикациями сизифа, чтобы пакеты могли устанавливаться в сборочную среду.