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)
Ответ на: комментарий от shimon

я могу выключить шаг с make test

Это по-моему другое. Ты можешь выбрать которые секции спека и стадии сборки выполнять.

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

Да, есть bcond и --with параметр у rpm. И они уже используются в некоторых местах. Питонщики например пока поддерживали два разных питона в одном спеке устраивали там вакналию из if-ов. Или часто делают if в зависимости от релиза.

Тут смысл в трёх вещах: 1) упрощении синтаксиса, 2) создании единого реестра таких флагов, 3) выбрасывании из спеков if-ов по типу if fedora, if centos и т.п., и вынесении конфига дистрибутива во внешний файл.

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

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

Вот эта идея с реестром мне не нравится. Спеки тем хороши, что они самодостаточны (теоретически). А сейчас начнется: как отдебажить каскад YAML’ов, почему вот в таком порядке, почему конфиг криво смержился, как сделать билд идентичный тому, что в дистрибутиве. Бррр.

Но вообще я заметил, что слишком многие спеки написаны неряшливо, многие build-зависимости, например, часто оказываются неуказанными, потому что «ну на моей машине эти заголовки есть», потом разработчики во время Mass Rebuild получают одно, а я в своем COPR получаю фигу, потому что там с чистого листа все делается.

Добавим сюда use-флаги, и будет вообще веселуха.

Ну и да, yaml, enlarge your attack surface…

shimon ★★★★★
()
Ответ на: комментарий от alpha
  1. выбрасывании из спеков if-ов по типу if fedora, if centos и т.п., и вынесении конфига дистрибутива во внешний файл.

Ох.

То есть ранее я мог построить на федоре пакет так, как он сделан в центоси, просто либо переменную подменив в командной строке, либо иф подправив. Если yaml лежит в /usr/share/чототам, это будет труднее.

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

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

потом разработчики во время Mass Rebuild получают одно, а я в своем COPR получаю фигу, потому что там с чистого листа все делается

Afaik при масс-ребилде там каждый пакет точно так же с чистого листа, то есть с минимального buildroot, отдельно собирается. При сборке каждый пакет ставит только свои build requires. «Массовость» там только в том смысле, что собранный пакет складывается в общую репу и становится доступным для установки следующим пакетам.

Так что это ты о какой-то другой проблеме говоришь.

А вообще конечно любые таки ветвления логики - это потенциальные проблемы. Но честно говоря мне кажется что централизация конфига в данном случае - это плюс.

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

А вот глобальный конфиг как раз можно будет прокинуть в mock и в copr. И иметь один для Fedora, один для EPEL.

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

Если yaml лежит в /usr/share/чототам, это будет труднее

А если он лежит в rpm-macros.rpm, который и так ставится в минимальное сборочное окружение?

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

Так что это ты о какой-то другой проблеме говоришь.

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

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

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

Тогда я правлю спек или передаю дефайны через командную строку. В новом RFC так тоже можно?

Мне по душе принцип, что из любой (вообще любой) ситуации есть escape hatch и любые умолчания легко перекрыть. Если этот принцип удастся сохранить, пуркуа бы и не па.

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

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

Есть способ сконфигурировать начальный набор пакетов. Базовый buildroot. И теоретически эта конфигурация в copr и в Fedora может отличаться. И в последние пару релизов этот базовый buildroot в Fedora чистили. Как минимум от питона.

Теоретически copr мог отстать, но тогда ситуация была бы наоборот.

А тот пакет который ты пересобирал, он в Fedora был свежесобранным? Или наследовался с предыдущих релизов?

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

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

In addition to overriding the defaults with –define, USE macros are fully compatible with RPM’s –with and –without RPM options, making local overrides for rebuilds and testing fairly simple.

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

Надо будет проследить чтобы этот use case в процессе обсуждения не потерялся.

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

Вот пример:

https://fedoraproject.org/wiki/Changes/Minimal_GDB_in_buildroot

@i_gnatenko_brain делал. После этого из базового buildroot пропала кучка пакетов. Всё что было собрано до того могло сломаться из-за нехватки зависимостей.

Но это было уже довольно давно.

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

Не, это у меня ложные воспоминания от сиживания дома. Как оно? Не в покер, а в преферанс, и не «Волгу», а «Жигуль», и не выиграл, а проиграл…

У меня есть подозрения насчет пакетов, принадлежащих KDE, что там некоторые зависимости первого порядка (которые ищет CMake) не прописаны, потому что их за собой тянут другие пакеты, от которых данный зависит. Не разбирался далее, потому что оно в конце концов работает. Но это неправильно, товарищи, так быть не должно! (Поправляет красный галстук) Во. Это одно.

А пакет, который наличествовал в Rawhide, и вроде даже в Mass Rebuild собрался, но в COPR не мог — это был webkit2gtk3. Там зависимости от перловых пакетов были прописаны так, что он под F32 и более поздние собраться не мог. Разве что последовательность сборки как-то повлияла на процесс.

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

Последовательность сборки могла сказаться, ну либо после него успели еще какую-нибудь несовместимость выкатить.

Мы сейчас работаем над тестом который перед выкаткой обновления в репу rawhide будет проверять не сломалась ли сборка всех зависящих от него пакетов. Но что-то пока медленно продвигаемся. Как оно заработает, жизнь станет попроще.

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

Ой, а можно еще будет сделать так, чтобы в COPR было какое-то простенькое отслеживание зависимостей на уровне спеков? Допустим, для сборки пакета Х нужен пакет У, но он еще не собран, так что мы соберем поначалу пакет У.

Сейчас у меня работает рецепт, хорошо экономящий мои силы и внимание, но изрядно жрущий электричество и облачный ресурс (вы же уже на AWS, да?) — цикл, в котором я тупо ставлю на пересборку все пакеты, упавшие на предыдущей итерации, пока все сборки не завершатся успехом. Для человека это хорошо, для инфраструктуры COPR, пожалуй, «могло бы быть лучше». Меня совесть мучает.

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

Тут смысл в трёх вещах

Нет!

Смысл иметь возможность выбора.

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

Думал они пойдут путем добавления суфиксов к rpm/deb пакетам, но возможно и пойдут по пути Gentoo - сборка на системе пользователя с исходных текстов с нужными опциями.

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

Мы сейчас работаем над тестом который перед выкаткой обновления в репу rawhide будет проверять не сломалась ли сборка всех зависящих от него пакетов.

Это очень ресурсоемко будет. Необходимы очень мощные сервера-кластеры для CI. Для домашних пользователей ccache поможет.

В Gentoo есть решение для проверки бинарников и либ: revdep-rebuild реализации аж две на bash и python.

Конкретно данный функционал «проверять не сломалась ли сборка всех зависящих от него пакетов» в Gentoo реализован изначально но не явно в portage - перезборка миров с разными USE флагами. Если кто замечает, что какой USE флаг что-то ломает то через багтрекер сообщают разрабам и те правят ebuild. По этому в Gentoo есть две ветки (amd64 - стабильна, ~amd64 - нестабильна), в стабильной все вылезано пользователями и разрабами, так что при использовании любых USE ничего не ломается.

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

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

man mockchain, нет? И, AFAIK, коппер использует mockchain.

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

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

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

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

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

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

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