Поступало предложение оформить, выражаясь образно, "точку входа в мир флатпаков" иначе: не переопределять префикс, а ввести режим:
  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 спеков?
> 
> В рамках сабжа этой баги точно ничего переводить никуда не надо. :)
Сабж связан с тем, что (по условию) у нас уже написаны спеки, и мы надеемся их переиспользовать, чтобы пакеты из сизифа появились в коллекции флатпаков.

(In reply to Arseny Maslennikov from comment #0)
> Будет целесообразно сделать так, чтобы спек от пакета из Сизифа, который
> уместно собрать не только в виде пакета, но и в виде флатпака, можно было
> собрать при помощи нашего rpmbuild, передав ему --define "_prefix /app".
Теперь так можно, начиная с 4.0.4.213-alt1.