Переход ROSA с RPM 5 на RPM 4

Материал из Rosalab Wiki
Перейти к: навигация, поиск
Начиная с rosa2019.1, дистрибутив ROSA Fresh переходит с пакетных менеджеров RPM 5 и urpmi на RPM 4 и DNF. Эта статья описывает основные отличия для пользователей и сборщиков пакетов.

Откуда куда перехода

Было:

  • низкоуровневая система управления пакетами RPM 5.4.10
  • высокоуровневый пакетный менеджер urpmi

Стало:

  • низкоуровневая система управления пакетами RPM 4.15.1+
  • высокоуровневый пакетный менеджер DNF

Затронутые платформы: rosa2019.1 (в будущем релизы Rosa Desktop Fresh >= R12, Rosa Enterprise Desktop >= X5) и новее, в старых пакетная система не меняется.

Причины для перехода

  • ни RPM 5, ни urpmi более не разрабатываются
  • в RPM 5 в свое время были важные функции, которых не было в RPM 4, но это более не так, теперь наоборот
  • апстрим RPM 4 в последнее время очень живой, RPM 4 активно развивается
  • плохое качество кода RPM 5: много весьма диких костылей времен спешного перехода Mandriva на RPM 5, много недоделанного функционала, отвечающий за что-то одно код размазан по огромному количеству файлов, например, см. коммит 5bf4d7: банально идентификаторы алгоритмов хеширования пришлось добавить в большое количество файлов
  • urpmi, конечно, немного жалко, но желающих в одиночку тянуть urpmi и perl-URPM не нашлось, а какого-либо критически важного функционала, отсутствующего в DNF, в urpmi нет

Общий план перехода

(возможны изменения, то, что еще не сделано, является приблизительным видением дальнейшей работы)

  • (СДЕЛАНО) собрать стек rpm4 с временными хаками, чтобы можно было использовать ранее собранные rpm5 пакеты *.rpm, например, игнорируя отсутствующую в стеке rpm4 %DISTEPOCH
  • (СДЕЛАНО) обеспечить совместимость нового rpm4 с максимально возможным количеством старых макросов
  • (СДЕЛАНО) автоматизированно внести массовые изменения в спеки (*.spec) так, чтобы они стали совместимы с RPM 4: меняются как места, которые строго необходимо заменить, так и те, где старый и продолжающий работать макрос меняется на его новый вариант
  • (СДЕЛАНО) обеспечить совместимость старого rpm5 с измененными спеками, чтобы можно было из одного спека собирать пакеты и для rpm5 в платформах rosa2016.1 и rosa2019.0 и для rpm4 в платформе rosa2019.1
  • (В ПРОЦЕССЕ) провести массовую пересборку пакетов main и contrib, выявив и исправив типовые проблемы (например, уже запатчен find-lang.sh из rpm4)
  • (В ПРОЦЕССЕ) ранее применявшимся в OpenMandriva скриптом автоматического обновления пакетов, где это возможно, обновить пакеты
  • привести файловые триггеры RPM 5 и %trigger* к файловым триггерам RPM 4
  • починить не собирающиеся пакеты, возможно, снова обновив glibc и gcc
  • либо отвязать drakxtools от perl-URPM, либо придется оставить urpmi в качестве существующего параллельно с DNF пакетного менедежера, как в Mageia
  • переработать пакет rosa-repos: вынести main, contrib, non-free и т.д. в отдельные подпакеты
  • собрать и обеспечить работу GUI для управления пакетами dnfdranoga
  • сделать генерацию метаданных appstream из всего репозитория
  • во все пакеты автоматически добавлять метаданные /usr/share/metainfo/*.xml, чтобы в графических "магазинах приложений" были все пакеты, а не только лишь те, в которых есть /usr/share/metainfo/*.xml; возможно, скрыть системные пакеты, имена которых начинаются на lib
  • обновить весь стек GNOME и затем обеспечить работу gnome-software
  • поскольку в drmdrake был GUI для управления репозиториями, а в dnfdranoga его нет, в пакеты rosa-repos-* добавить метаданные с описанием назначения этих репозиториев и с его переводом на русский язык; в магазинах приложений сделать отдельную категорию пакетов "Репозитории ROSA"; это позволит включать и отключать репозитории одной кнопкой "Установить"/"Удалить" пакет, также улучшит централизацию поставки конфигураций репозиториев
  • собрать, обновить и обеспечить работу packagekit
  • обеспечить работу оффлайн-обновлений через packagekit+systemd
  • ...

Особенности перевода спеков на RPM 4

Скрипт rpm5-to-rpm4.sh, который автоматически вносит правки в спеки, здесь: https://gitlab.com/abf-mirror/abf-mirror-scripts

  • Suggests и Requires(missingok) теперь Recommends: в RPM 5 были только Suggests и Requires(missingok) (а Suggests был алиасом Requires(missingok), а в RPM 4 есть и то, и то, но Recommends работает так, как работал Suggests, а Suggests используется для иных вещей, поэтому заменяем "Suggests:" на "Recommends:", а чтобы такие спеки продолжали работать в RPM 5, мы научили его понимать Suggests: теперь он считает и Suggests, и Recommends одинаково эквивалентными "Requires(missingok)"
  • Фильтры для автоматического генератора зависимостей (requires) и провайдов (provides) поменялись следующим образом, ниже сначала вариант RPM 4 (новый), затем RPM 5 (старый):
 * %__requires_exclude -> %__noautoreq
 * %__provides_exclude -> %__noautoprov
 * %__requires_exclude_from -> %__noautoreqfiles
 * %__provides_exclude_from -> %__noautoprovfiles

Нет возможности легко научить RPM 4 понимать %__noautoreq, %__noautoprov, %__noautoreqfiles и %__noautoprovfiles, но есть возможность легко научить RPM 5 понимать оба варианта, что мы и сделали. Теперь, если в спеке указаны одновременно старый макрос и эквивалентный ему новый макрос, например:

 %define __noautoreq 'libGL.*'
 %global __requires_exclude 'libGL.*'

...то rpm5 будет брать только значение старого (__noautoreq) и игнорировать новый (__requires_exclude). Если же указан только новый (__requires_exclude), то будет браться его значение. В большинстве случаев достаточно использовать только новый вариант от RPM 4, но, если вдруг понадобится задать разные правила для RPM 5 и RPM 4, то укажите оба варианта, тогда RPM 5 возьмет только свой прежний вариант, а RPM 4 только свой. Обратите внимание, что RPM 4 не понимает старые варианты от RPM 5, поэтому для RPM 4 обязательно указать __requires_exclude, а не __noautoreq.

Мы досканально не изучали особенности раскрытия регулярных выражений в этих макросах-фильтрах, возможны нюансы, новые варианты сделаны эквивалентными старым для большинства типовых случаев.