LINUX.ORG.RU

USE-макросы в rpm-пакетах

 ,


1

3

В рассылке Fedora опубликовано предложение по стандартизации макросов в спек-файлах RPM, позволяющее добавить в RPM-пакеты возможность выбора флагов компиляции и дополнительных зависимостей на этапе сборки.

Пример использования:

%if %{use ssl}
BuildRequires:  openssl-devel
%endif

%prep
%configure %{use_enable ssl openssl}

%check
make test %{?_use_ssl:-DSSL}

В этом примере при задании USE-макроса ssl в спек-файле будет добавлена дополнительная зависимость на пакет openssl-devel, будет выполнен шаг конфигурации с включенной опцией --enable-openssl, а также при сборке будут выполнены соответствующие тесты.

Предполагается что опция сборки будет задаваться бинарным макросом %_use_<feature> с дополнительными обертками вида:

  • %{use <feature>} – принимает значения 0 или 1,
  • %{use_enable <feature> [<configure name> [<configure option>]]} – разворачивается в --disable-<feature> или --enable-<feature>.

Добавление опций такого вида в спек-файлы позволит собирать различные варианты дистрибутива из одних и тех же исходников.

Например, для минимизации дерева build-зависимостей можно будет использовать глобальный параметр %{use docs} отключающий сборку документации.

Задавать подходящий набор опций можно будет сконфигурировав сборочное окружение. Причем опции можно будет задать как глобально, так и переопределив отдельно по каждому пакету.

Предложение пока не принято и находится на стадии обсуждения.

>>> Обсуждение в рассылке

★★★★★

Проверено: cetjs2 ()
Последнее исправление: cetjs2 (всего исправлений: 2)

Ответ на: комментарий от alpha

Сколько пакетов нужно будет исправить?

Все 3000 спецификаций сборки!

А иначе никак, ибо одним надо только 2, другим 3, а некоторым уже 4.

anonymous
()
Ответ на: комментарий от siraenuhlaalu

Дык ты при сборке зависимости резолвишь не по дереву rawhide, а по дереву твоей старой федоры.

Именно. А если бы ресолв производился еще и по спекам в самом коппере…

shimon ★★★★★
()
Ответ на: комментарий от alpha

Контейнеризация и модули уже решили эту проблему. А ценность виртуальных окружений специфичных для экосистемы конкретного языка весьма спорна. Большинство py-окружений вылезают за рамки virtualenv.

Это если там есть монстр типа pygobject. 90% остальных — вполне влезает.

С другой стороны, чуть ли не 99% всего, что есть в RPM, завязано на сишно-автотулзовое configure && make && make install, а остальные системы сборки втискивают в это прокрустово ложе — из-за чего, например, растовые пакеты и их сборка выглядят по-растамански, и ничо, и не помер никто.

shimon ★★★★★
()
Ответ на: комментарий от mx__

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

t184256 ★★★★★
()
Ответ на: комментарий от shimon

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

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

В альтлинуксе постоянно пережимали с этим.

AVL2 ★★★★★
()
Ответ на: комментарий от mx__

Да. Чтобы при желании ты понакладывал патчей или подкрутил опций сборки и дистр стал вести себя в этих местах как source-based — собирать и даже сам пересобрать при обновлениях.

t184256 ★★★★★
()
Ответ на: комментарий от t184256

Подсунь макросами самбе пропатченный gnutls. Так, чтобы остальным, естественно, непропатченный. Без замораживания версии gnutls во времени.

Я с mc так делаю: https://abf.rosalinux.ru/import/mc

# Highlight hidden files and dirs with black and
# whitespaces (in mcedit) with bright red like it was in mc 4.6.3 aka Russian fork
# Don't highlight syntax for .yml files
Patch0:		mc-4.8.20-old-style-defaults.patch
%if %{with mc46_style}
%patch0 -p1 -b .mc46-style~
%else
%patch1 -p1 -b .tabs~
%endif```
Pulfer
()
Последнее исправление: Pulfer (всего исправлений: 1)
Ответ на: комментарий от Pulfer

Лол, нет, ты патчишь mc. Это-то в любом дистре/ПМ можно. Пропатчь зависимость mc, не затронув остальных пользователей этой зависимости. Потом погляди на оставшихся два предложения и признай, что RPM на это не рассчитан.

t184256 ★★★★★
()
Ответ на: комментарий от t184256

Потом погляди на оставшихся два предложения и признай, что RPM на это не рассчитан.

А, ну да. Но я вообще не очень представляю, как это сделать, не используя статические библиотеки или rpath, чтобы две разные версии gnutls держать и использовать.

Pulfer
()
Ответ на: комментарий от Pulfer

Ну, давай считать:

  1. LD_PRELOAD

  2. rpath

  3. LD_LIBRARY_PATH на специально созданную директорию (с ограничениями, но все же)

  4. runpath

  5. линковка к абсолютному пути

  6. своя реализация линковки

Ничего не забыл?

t184256 ★★★★★
()
Ответ на: комментарий от t184256

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

L29Ah
()
Ответ на: комментарий от t184256

Подсунь макросами самбе пропатченный gnutls. Так, чтобы остальным, естественно, непропатченный.

Зачем?

dexpl ★★★★★
()
Ответ на: комментарий от dexpl

Чтобы в одну строчку развернуть самбу с пропатченным gnutls. Или протестить, не поломав «установленную в системе». То, что твой любимый ПМ ниче не умеет, ещё не значит, что это автоматом «ненужно».

t184256 ★★★★★
()
Ответ на: комментарий от t184256

Чтобы в одну строчку развернуть самбу с пропатченным gnutls.

Что ж там за патчи такие у gnutls, что с ними надо развертывать самбу и только самбу? Спрашиваю как подписчик samba-devel@.

Или протестить, не поломав «установленную в системе».

Протестить на боевой системе? Однако…

dexpl ★★★★★
()

да чет я аж всплакнул по сабайону ‘;’*(

zor1984qq
()
Ответ на: комментарий от t184256

Есть пример пакетов, которые зависят от других пакетов, оверрайднутых определённым образом?

L29Ah
()
Ответ на: комментарий от t184256

Думаю, ещё

  1. Поменять soname у пропатченной либы gnutls. Но это и с RPM можно.
Pulfer
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.