LINUX.ORG.RU

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

 ,


1

4

В рассылке 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 ()

А до сейчас разве не был какой-то самопал в виде условных переменных, которые можно было этосамое с командной строки? Ну допустим, мне все равно, пройдет ли make test, и я могу выключить шаг с make test. Это ж уже сто лет как было, нет? Сам помню, пользовался.

Ну и для опциональной сборки некоторых подпакетов же ж все равно придется рассеять %ifов разнокалиберных по всему спеку, разве нет?

А потом, мне немного страшно делается на мысль о том, какие волшебные баги породят слишком ретивые пакетописатели. Вот недавно мне надо было на XScreenSaver федоровский наложить патчик, так после лицезрения xscreensaver.spec мне пришлось валерианой закидываться.

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

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

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

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

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

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

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

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

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

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

Чуть позже они поймут, что есть взаимоисключающие флаги, есть зависимые флаги, есть кейс когда один флаг требует зависимость с определенным флагом, есть глобальные флаги, но есть per-package флаги...

Вобщем, как указали выше - изобретают то, что уже давно изобретено.

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

Что то я не понял, все это я использую более 10 лет (может более 20 уже). И эти наборы макросов тоже давно есть. В чем суть новости непонятно.

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

А как оно будет с разными системами сборки работать? Например, тот же openssl собирается scons (тк писался инопланетянами).

Ну и потом, вот говорю я use-ssl, но имею в виду не openssl, а libressl, как такие вещи будут обрабатываться?

DELIRIUM ☆☆☆☆☆ ()
Ответ на: комментарий от Atlant

Даешь объединение *.src.deb, *.spec, *.ebuild и т.д!

Не надо путать грешное с праведным.

Мухи пусть будут отдельно, от котлет.

Проблемы индейцев нас вообще волновать не должны…

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

Чуть позже они поймут, что есть взаимоисключающие флаги, есть зависимые флаги, есть кейс когда один флаг требует зависимость с определенным флагом, есть глобальные флаги, но есть per-package флаги…

Если они только в 2020 году поняли что пользователю все-же необходима свобода выбора то «Чуть позже» у них наступит не скорее 2040 года.

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

Нет, не обращай внимания на гентушников, они просто увидели знакомые слова и реагируют. Использование rpmbuild или mock, соответственно ковыряние в spec-файлах, никаким образом не рассматривается как инструменты конечного пользователя, пользоваться ими удобно и приятно, однако, пользователь федоры может спать спокойно ничего не зная о них совсем. Просто большие парни ищут способы оптимизации и рационализации процессов сборки, которая вообще может быть автоматической, вот и обсуждают всякое.

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

Когда-то и kde собирался с помощью scons.

Сейчас он остался в основном в научном софте, особенно если он python в рамках проекта дополнительно хочет. Некоторая прелесть в нём есть - изолированное сборочное окружение, но передать какие-то новые переменные окружения иногда не так просто.

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

большие парни ищут способы оптимизации и рационализации процессов сборки, которая вообще может быть автоматической

А это разве не автоматическая сборка ??

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

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

говорю я use-ssl, но имею в виду не openssl, а libressl, как такие вещи будут обрабатываться?

Tak и говоришь, с помощью USE, какому ssl больше всего веришь: bearssl gcrypt kernel libressl nettle openssl wolfssl.

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

Наличие таких флагов подразумевает разные опции сборки. Шаблоны, удобно, да. Но собранные по разному пакеты будут иметь и разные последствия. И криворукие оптимизаторы лора возьмутся выпиливать «ненужное».

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

большие парни ищут способы

А это разве не автоматическая сборка ??

Так это же для людей сделано. А эти каждый пакет руками собирают и в общую репу добавляют, один для всех и на все случаи жизни.

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

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

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

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

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

Они только думают как это сделать, но сами пока не знают как.

Вариант 1

USE=«bearssl gcrypt kernel libressl nettle +openssl wolfssl»

Определяет возможность выбора для пакета с openssl по умолчанию. И они сначала сделают этот.

Вариант 2.

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

Еще поразмыслив поймут что есть зависимые флаги, выбор USE=ssl требует указать одну и только одну крыпто библиотеку. И все это должно просчитывается не для одного выбранного пакета, а глобально для всех пакетов в системе.

И наконец, когда этих USE в бинарном дистре станет больше 5 (для каждого варианта комбинаций придется собирать отдельный пакет rpm со своим суфиксом) придет «большой парень» с ремнем и разгонет школоту которая USE в бинарный дистр засунула.

anonymous ()