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)

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

emerge -v –deep –newuse –update –with-bdeps=y –backtrack=99 @world

Да и правда, чё процессор простаивает без дела! (ха, кастанули какого-то world-а)

papin-aziat ★★★★★
()
Ответ на: комментарий от ChekPuk

И криворукие оптимизаторы лора возьмутся выпиливать «ненужное».

Что мешает им делать это сейчас? Вот тебе конкретный пример: в centos-8 evince идет без djvu, хочешь читать – пересобирай, я так и сделал, самый что ни на есть криворукий ЛОРовец.

papin-aziat ★★★★★
()
Ответ на: комментарий от anonymous

Ладно, не надо рассыпать жемчуг перед …

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

papin-aziat ★★★★★
()
Ответ на: комментарий от ChekPuk

В данном случае наиболее вероятным выпиливателем будет не конечный пользователь, а например CentOS/RHEL.

И будет бегать со своими ошибками конечно, но так и решать их придётся ему же.

alpha ★★★★★
() автор топика

Даешь USE=-systemd

Иначе - «ненужно»

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

а они всё выпиливают

Было и такое, с мусей, пришлось отказываться от сборки документации, ибо зависимость(ненужную мне вообще) не удавалось разрешить из-за версии, а так же убрать ряд зависимостей(муз-шрифты и тд, я точно знаю, что надо для корректной работы), чтобы упростить сборку и установку, кстати, вот может эти use-макросы и будут ништяками в таких случаях.

papin-aziat ★★★★★
()
Ответ на: комментарий от ierton

Предвижу revdep-rebuild hell.

У них и так порой бывает «*.so hell», только без «revdep-rebuild».

Atlant ★★★★★
()

Red Hat постоянно экспериментирует со всякими ненужностями.

Поэтому рулит Mageia.

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

Не знаю. Там точно пакеты по одному собираются? Я вот играюсь тем, что у меня в COPR собираются кеды и гном из Rawhide для текущей стабильной ветки (люблю обмазаться свежим KDE и проч.). Так у меня приняли даже пару-тройку PR’ов, которые прописывали билд-зависимости в явном виде, ибо пакеты не собирались ни в какую

Дык ты при сборке зависимости резолвишь не по дереву rawhide, а по дереву твоей старой федоры. При этом в спеке должны указываться только непосредственные зависимости пакета, а не все рекурсивно. Что приводит к тому, что если в твоём репозитории пакет из зависимостей распилен на какие-то составляющие относительно rawhide, эти сборочные зависимости могут быть утеряны. Аналогично в случае переименований или радикальных обновлений. Типа Provides: Python будет резолвиться в python-2.X и python-3.X в зависимости от версии дистрибутива.

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

подход Nix - это луддизм, мы не осилили разрулить динамические зависимости и теперь будем всё собирать статикой

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

srpms это и есть эквивалент ebuild-ов. Нужна теперь система типа portage, которая при изменении USE-флагов будет пересобирать нужные src.rpm-ы и устанавливать их.

да подобную примочку можно и сейчас прикрутить

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

другое дело, что если не собирать полностью всю систему из исходников, а только отдельные пакеты, то смысла от такого и не будет

как я понял, эта фича в первую очередь не для пользователей, а для мейнтенеров пакетов под разные редхато-диревативы

P.S. а разве эта новость не проскакивала уже 2-3 недели назад? или я с опеннетом перепутал, точно помню что уже читал про это на русском

actionless ★★★★★
()

Повторяю вопрос (первый раз что то не прокатило)

Взял первый попавший spec что собирал давно ...

%if 0%{?with_python3}
BuildRequires:  python3-devel
%endif
%if 0%{?fedora}
%global with_python3 1
%endif
%if 0%{?rhel} && 0%{?rhel} <= 6
BuildRequires: python-mock
%else
BuildRequires: python2-mock
%endif

Можно еще посмотреть в /usr/lib/rpm/platform/ и подобное, там этих макросов под любую платформу большая куча.

mx__ ★★★★★
()
Последнее исправление: mx__ (всего исправлений: 3)

Плохая идея, если имя пакета не изменяется. Идею надо довести до логического конца - NixOS/Nix.

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

Есть у меня подозрение, что RPM-based дойдут до этого логического конца примерно никогда, если не позже.

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

Так и так можно макросами что угодно подсунуть. Причем эти переменные можно и так пихать типа : rpmbuild --with_samba *.srpm

Пишу по памяти но как то так.

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

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

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

Идея в том чтобы вот этот кусок

%if 0%{?fedora}
%global with_python3 1
%endif

вынести с уровня пакета на уровень дистрибутива.

Плюс синктаксис попроще.

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

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

Да, но зачем?

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

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

Абстрактно? Потому что ПМ должен уметь такие вещи и многое другое, а импотентный RPM даже virtualenv юзеру сделать не может. 21 век на дворе.

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

Для бинарных пакетов USE смысла не имеет. И выше упоминали что речь про src-пакеты. Так что кто здесь несёт чушь, это ещё большой вопрос.

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

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

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

RPM - это технология пакетирования, которая включает в себя формат спек-файлов, утилиты сборки, формат src.rpm пакетов с исходниками, формат бинарных .rpm-пакетов и т.д. и т.п.

Ты прикопался к словам на пустом месте.

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

Контейнеризация и модули уже решили эту проблему.

Ни капли. Контейнеризация — новое окружение с кучей непрошенного гемора, а про модули давай лучше вообще не будем. Боюсь, что мой пример с самбой и gnutls, который в Nix был бы однострочником, решить с помощью модулей в разумные сроки смогут, ИМХО, разве что наши с тобой коллеги. А в Виллабаджо тем временем все решится само пока я за чаем схожу.

А ценность виртуальных окружений специфичных для экосистемы конкретного языка весьма спорна.

Че тут спорного, они откровенно вредны, потому что не умеют разруливать кросс-экосистемные зависимости, а нормальным ПМ только отправляют жизнь (см. войну cargo и Nix). ПМ должен быть один и мочь все, в том числе виртуалэнвы для объединения всех экосистем разом.

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

Боюсь, что мой пример с самбой и gnutls, который в Nix был бы однострочником, решить с помощью модулей в разумные сроки смогут, ИМХО, разве что наши с тобой коллеги

Как раз в более широком сообществе модули, имхо, зайдут на ура.

В Fedora oldschool-народ выпал в осадок от одного простого yaml-файла и необходимости читать целую страницу новых доков. Из-за чего устроил маленькую войну с разработчиками. Во внешнем мире yaml уже давно никого не пугает, а сборка модуля с фиксом состоит в том, чтобы указать новый git hash, с которого стоит собирать пакет.

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

вынести с уровня пакета на уровень дистрибутива.

Наверное я не понимаю. Но есть же файлы наборы макросов и помоему в зависимости от дистра.

И вообще это : %if 0%{?rhel} && 0%{?rhel} <= 6 разве не выбор дистра ?

Плюс синктаксис попроще.

Ну если только это.

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

Представть что у тебя 3000 python-пакетов.

В каждом из них в спеке есть строчки:

%if 0%{?fedora}
%global with_python3 1
%endif

И тут fedora решила перейти на python 4.

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

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

Я в RPM-мире новичок, но модули все равно считаю эмуляцией того как надо, а не решением по существу.

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

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

Контейнеризация и модули уже решили эту проблему.

А модули по сравнению с sclo вообще шаг назад. Я мог иметь в системе сразу 3 разных питона. А с модулями что ? Только 1 и для другого нужно крячить контейнер :(

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

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

Один. Файл с макросами. Где как раз и определяется ЭТОТ глобал.

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

а там Nix уже не первое десятилетие не знает, чем заняться

Удивительно почему, да? :)

Модули как раз круты тем что они не нарушают структуру ни rpm-пакетов, ни файловой системы.

В отличие от тех же software collections которые больше похожи на твой nix и ставили софт по каким-то своим путям в строне в /opt, модульные пакеты - это обычные rpm-пакеты. У них разные только опции сборки и buildroot, в котором эта сборка происходит.

То есть тебе не надо держать отдельно спек системного пакета nginx и спек модульного. Это один и тот же спек. Необязательно даже бранчеваться. Просто взял и собрал модуль с коммита мастер-ветки rawhide, но трехнедельной давности.

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

контейнер не нужно «крячить», его давно можно взять и запустить

Это просто процесс запущенный в подходящем namespace. Если выкинуть докер, то там практически не остается магии.

А про scl я тут в феврале слушала доклад на CentOS Dojo о том как это майнтейнится в центоси. Эта картина страшна в своей безысходности.

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

Это потому что так спеки написали. Написали бы нормально и не было бы проблем.

cat /usr/lib/rpm/macros.python                                                               
# Python specific macro definitions.
# To make use of these macros insert the following line into your spec file:
# %include %{_rpmconfigdir}/macros.python

То что sclo в opt это фигня, вот то что спек один и тот же это +, тут без вопросов. Но накладные расходы в виде контейнров напрягают, хотя какая разницу куда и на каком уровне работает чанж-рут.

P.S. Фиг с ним с отказа от sclo в модуля, это не совсем та тема.

mx__ ★★★★★
()
Последнее исправление: mx__ (всего исправлений: 1)
Ответ на: комментарий от alpha

И кстати тот же к примеру ssl (как в примере) вот переделают его на ssl2 (к примеру) и теже 4000 спека нужно будет исправить.

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

Удивительно почему, да? :)

Да вообще-то нет. =D

В отличие от тех же software collections которые больше похожи на твой nix

Вот ни капли.

То есть тебе не надо держать отдельно спек системного пакета nginx и спек модульного. Это один и тот же спек. Необязательно даже бранчеваться.

И все равно не будет такой гибкости, как у Nixовых override’ов, где можно даже для транзитивной зависимости подправить произвольный атрибут как нефиг делать, не удостаивая это лишних слов и абстракций. Прям в системном конфиге.

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

Насколько я понял nixos это не бинарный дистр, так что он не пригоден для работы, если у вас нет цели платить кучу денег за электроэнергию.

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

Он непригоден для работы по совершенно другим причинам. Годами юзать NixOS ничего не компилируя совершенно реально.

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

Для бинарных пакетов USE смысла не имеет. И выше упоминали что речь про src-пакеты. Так что кто здесь несёт чушь, это ещё большой вопрос.

Ты чушь несешь. При чем тут пакеты? Если речь шла о дистрибутиве:

Кто не принял генту, тот обречён её переизобретать

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

Было б здорово, если бы уже рассыпанный жемчуг собрали за собой, …

Аноним на модер, написаное не тиет. Может найдутся те кому советы помогут.

Вот за твое оскорбление оставлю без ответа следующие:

цикл, в котором я тупо ставлю на пересборку все пакеты, упавшие на предыдущей итерации, пока все сборки не завершатся успехом.

а мог бы и помочь братьям меньшим из федорки.

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

вынести с уровня пакета на уровень дистрибутива.

А если одному пакету надо питон2, а другому питон3?

Согласен, что существуют «общесистемные зависимости», но они следствие, а зависимости пакета первичны.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.