Ряд участников (и кандидатов в) ALT Linux Team взяли на себя инициативу организовать упаковку избранных пакетов из Сизифа и их публикацию в виде "флатпак-приложений". Вот одна из причин этим заниматься: сообщество сможет предоставить пользователям ОС на бранч-платформах возможность одной командой (или одним кликом) на свой страх и риск установить себе пакет из Сизифа в изолированное окружение вместе с его зависимостями из Сизифа, не нарушая консистентность ОС и пакетов из платформы. Как известно, флатпак-артефакты для распространения пользователям делятся на два типа: "приложение" (app) и "среда исполнения" (runtime). Первые могут содержать зависимости на вторые. Файлы внутри артефактов первого и второго типов расположены по-разному; в частности, в "приложениях" присущие им файлы упакованы в каталог `/app`. (Исполняющая среда при помощи bind mount и других программных средств добивается, чтобы программы внутри видели FHS-дерево.) В "средах исполнения" файлы расположены как обычно; туда кладут, например, согласованный набор библиотек. В этой баге мы говорим только о "флатпак-приложениях". Будет целесообразно сделать так, чтобы спек от пакета из Сизифа, который уместно собрать не только в виде пакета, но и в виде флатпака, можно было собрать при помощи нашего rpmbuild, передав ему --define "_prefix /app". В такой сборке будет задействован немного другой макронабор, тот же набор brp (некоторые из них будут no-op, напр. brp-dupe-bin); а sisyphus-check будет неактуален.
Поступало предложение оформить, выражаясь образно, "точку входа в мир флатпаков" иначе: не переопределять префикс, а ввести режим: rpmbuild --define "_rootlayout fhs" "$@" rpmbuild --define "_rootlayout flatpak-app" "$@" и при первом из указанных значений (оно же по умолчанию) упаковывать файлы для традиционных пакетов, как обычно, а при втором упаковывать файлы для flatpak. Надо подумать, лучше ли это, чем решить, что '_prefix /app' — это всегда наш случай. Но есть и подзадачи более высокого приоритета.
Почему это должен решать rpmbuild?
(In reply to Vitaly Chikunov from comment #2) > Почему это должен решать rpmbuild? В сизифе есть много успешно, по мере сил воспроизводимо собирающихся спеков с программами в духе [1][2][3]. [1] https://packages.altlinux.org/en/sisyphus/srpms/hieroglyphic/ [2] https://packages.altlinux.org/en/sisyphus/srpms/lemma/ [3] https://packages.altlinux.org/en/sisyphus/srpms/picplanner/ Макродвижок rpmbuild, как пока представляется, позволяет малыми усилиями, собрав наш спек с немного другим значением парочки макросов, получить пакет, дерево файлов которого будет пригодно для перекладывания в F-артефакт. Станет не нужно мейнтейнить два разных build definition: одно на базе rpmspec, другое на синтаксисе YAML (yikes). А вот зависимости будут устроены по-другому; нужно будет конвертировать граф rpm-ных зависимостей в такой, что приличествует коллекции "приложений" и "рантаймов" под рабочим кодовым названием, допустим, "альтхаб", которая естественно возникнет. И мне теоретически кажется, что rpmbuild здесь ничем не поможет и не помешает, но, полагаю, прямые участники проекта смогут прокомментировать яснее.
(In reply to Arseny Maslennikov from comment #0) > В этой баге мы говорим только о "флатпак-приложениях". > > ...В такой сборке будет задействован немного другой макронабор, тот же набор > brp (некоторые из них будут no-op, напр. brp-dupe-bin); а sisyphus-check будет > неактуален. ...в неизменном виде. Некоторые проверки станут не нужны, появятся новые; это будет форк sisyphus-check.
(In reply to Arseny Maslennikov from comment #3) > (In reply to Vitaly Chikunov from comment #2) > > Почему это должен решать rpmbuild? > В сизифе есть много успешно, по мере сил воспроизводимо собирающихся спеков > с программами в духе [1][2][3]. > > [1] https://packages.altlinux.org/en/sisyphus/srpms/hieroglyphic/ > [2] https://packages.altlinux.org/en/sisyphus/srpms/lemma/ > [3] https://packages.altlinux.org/en/sisyphus/srpms/picplanner/ > > Макродвижок rpmbuild, как пока представляется, позволяет малыми усилиями, > собрав наш спек с немного другим значением парочки макросов, получить пакет, > дерево файлов которого будет пригодно для перекладывания в F-артефакт. > Станет не нужно мейнтейнить два разных build definition: одно на базе > rpmspec, другое на синтаксисе YAML (yikes). Если разница будет слишком большой и потребует сопровождения, то мы унесём макроопределения для "ф-приложений" в отдельный пакет rpmb-config-что-то, чтобы не мозолили глаза в репозитории rpm-build. (Вообще, держать macros.in, platform.in, etc. в другом пакете — это в целом хорошая идея.)
(Ответ для Arseny Maslennikov на комментарий #3) > (In reply to Vitaly Chikunov from comment #2) > > Почему это должен решать rpmbuild? > > В сизифе есть много успешно, по мере сил воспроизводимо собирающихся спеков > с программами в духе [1][2][3]. > > [1] https://packages.altlinux.org/en/sisyphus/srpms/hieroglyphic/ > [2] https://packages.altlinux.org/en/sisyphus/srpms/lemma/ > [3] https://packages.altlinux.org/en/sisyphus/srpms/picplanner/ > > Макродвижок rpmbuild, как пока представляется, позволяет малыми усилиями, > собрав наш спек с немного другим значением парочки макросов, получить пакет, > дерево файлов которого будет пригодно для перекладывания в F-артефакт. > Станет не нужно мейнтейнить два разных build definition: одно на базе > rpmspec, другое на синтаксисе YAML (yikes). > > А вот зависимости будут устроены по-другому; нужно будет конвертировать граф > rpm-ных зависимостей в такой, что приличествует коллекции "приложений" и > "рантаймов" под рабочим кодовым названием, допустим, "альтхаб", которая > естественно возникнет. И мне теоретически кажется, что rpmbuild здесь ничем > не поможет и не помешает, но, полагаю, прямые участники проекта смогут > прокомментировать яснее. То есть есть желание перевести yaml манифесты в формат rpm спеков?
(In reply to Vladimir Romanov from comment #6) > (Ответ для Arseny Maslennikov на комментарий #3) > > (In reply to Vitaly Chikunov from comment #2) > > > Почему это должен решать rpmbuild? > > > > В сизифе есть много успешно, по мере сил воспроизводимо собирающихся спеков > > с программами в духе [1][2][3]. > > > > [1] https://packages.altlinux.org/en/sisyphus/srpms/hieroglyphic/ > > [2] https://packages.altlinux.org/en/sisyphus/srpms/lemma/ > > [3] https://packages.altlinux.org/en/sisyphus/srpms/picplanner/ > > > > Макродвижок rpmbuild, как пока представляется, позволяет малыми усилиями, > > собрав наш спек с немного другим значением парочки макросов, получить пакет, > > дерево файлов которого будет пригодно для перекладывания в F-артефакт. > > Станет не нужно мейнтейнить два разных build definition: одно на базе > > rpmspec, другое на синтаксисе YAML (yikes). > > > > А вот зависимости будут устроены по-другому; нужно будет конвертировать граф > > rpm-ных зависимостей в такой, что приличествует коллекции "приложений" и > > "рантаймов" под рабочим кодовым названием, допустим, "альтхаб", которая > > естественно возникнет. И мне теоретически кажется, что rpmbuild здесь ничем > > не поможет и не помешает, но, полагаю, прямые участники проекта смогут > > прокомментировать яснее. > > То есть есть желание перевести yaml манифесты в формат rpm спеков? Наша team накопила большой опыт (преимущественно негативный) машинного анализа и обработки rpm-спеков; в общем случае они ему без eval не поддаются, а частичный анализ по принципу "надежда умирает последней", как в проекте gear, хрупок. Так что у меня такого желания нет, и я никому этот тернистый путь не рекомендовал бы. YAML тоже страдает от подобных проблем[1][2][3], только он ещё и с трудом человекопознаваемый, склонен мешать человеку по принципу револьвера с одним патроном: почти всегда щелчок, а иногда [ДАННЫЕ УДАЛЕНЫ]. Это чуть ли не худший тип стохастических явлений с т. з. человеческой психики. [ Можно в теории (выходим за пределы онтопика, конечно) захотеть построить подмножество yaml, которое однозначно и очевидно парсится без исполнения произвольного кода, сохранив те свойства, которым этот синтаксис удобен и вообще в рамках сизифа уезжать туда (генерировать из него и rpm-спеки, и флатпак-спеки). Но за эту high toll, high reward метазадачу никто не брался, а когда предварительно обсуждали, тяготели скорее к debian control. ] [1] https://www.ohyaml.wtf/ [2] https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell [3] https://github.com/ghuntley/noyaml/blob/db7b929f99c42e0f792c7322438297ec9ee6331d/index.html В рамках сабжа этой баги точно ничего переводить никуда не надо. :)
(In reply to Arseny Maslennikov from comment #7) > (In reply to Vladimir Romanov from comment #6) > > (Ответ для Arseny Maslennikov на комментарий #3) > > > Макродвижок rpmbuild, как пока представляется, позволяет малыми усилиями, > > > собрав наш спек с немного другим значением парочки макросов, получить пакет, > > > дерево файлов которого будет пригодно для перекладывания в F-артефакт. > > > Станет не нужно мейнтейнить два разных build definition: одно на базе > > > rpmspec, другое на синтаксисе YAML (yikes). > > > > > > А вот зависимости будут устроены по-другому; нужно будет конвертировать граф > > > rpm-ных зависимостей в такой, что приличествует коллекции "приложений" и > > > "рантаймов" под рабочим кодовым названием, допустим, "альтхаб", которая > > > естественно возникнет. И мне теоретически кажется, что rpmbuild здесь ничем > > > не поможет и не помешает, но, полагаю, прямые участники проекта смогут > > > прокомментировать яснее. > > > > То есть есть желание перевести yaml манифесты в формат rpm спеков? > > В рамках сабжа этой баги точно ничего переводить никуда не надо. :) Сабж связан с тем, что (по условию) у нас уже написаны спеки, и мы надеемся их переиспользовать, чтобы пакеты из сизифа появились в коллекции флатпаков.
