ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | раскладка buildroot для упаковки как "флатпак-приложение" | ||
|---|---|---|---|
| Product: | Sisyphus | Reporter: | Arseny Maslennikov <arseny> |
| Component: | rpm-build | Assignee: | placeholder <placeholder> |
| Status: | NEW --- | QA Contact: | qa-sisyphus |
| Severity: | normal | ||
| Priority: | P5 | CC: | antohami, armatik, arseny, glebfm, imz, ldv, oleg, placeholder, radiolamp, rirusha, vt |
| Version: | unstable | ||
| Hardware: | all | ||
| OS: | Linux | ||
| Bug Depends on: | 57706 | ||
| Bug Blocks: | |||
|
Description
Arseny Maslennikov
2026-01-25 16:39:59 MSK
Поступало предложение оформить, выражаясь образно, "точку входа в мир флатпаков" иначе: не переопределять префикс, а ввести режим: 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 спеков? > > В рамках сабжа этой баги точно ничего переводить никуда не надо. :) Сабж связан с тем, что (по условию) у нас уже написаны спеки, и мы надеемся их переиспользовать, чтобы пакеты из сизифа появились в коллекции флатпаков. |
