Надо обновить manuals.

(Ответ для Yuri N. Sedunov на комментарий #1)
> Надо обновить manuals.

Обновил: https://packages.altlinux.org/ru/tasks/404525/

(Ответ для Semen Fomchenkov на комментарий #2)
> (Ответ для Yuri N. Sedunov на комментарий #1)
> > Надо обновить manuals.
> 
> Обновил: https://packages.altlinux.org/ru/tasks/404525/

$ manuals 

(manuals:1411924): GLib-GIO-ERROR **: 23:33:37.292: Settings schema 'app.devsuite.foundry' is not installed
Ловушка трассировки/останова

(Ответ для Yuri N. Sedunov на комментарий #3)
> (Ответ для Semen Fomchenkov на комментарий #2)
> > (Ответ для Yuri N. Sedunov на комментарий #1)
> > > Надо обновить manuals.
> > 
> > Обновил: https://packages.altlinux.org/ru/tasks/404525/
> 
> $ manuals 
> 
> (manuals:1411924): GLib-GIO-ERROR **: 23:33:37.292: Settings schema
> 'app.devsuite.foundry' is not installed
> Ловушка трассировки/останова

Думаю ошибка в упаковке foundry, почему-то схема glib лежит в CLI утилите, хотя её использует библиотека, и логично было бы CLI утилите поставить зависимость на библиотеку. Буду обсуждать с сопровождающим foundry исправление.

(In reply to Semen Fomchenkov from comment #4)
> Думаю ошибка в упаковке foundry, почему-то схема glib лежит в CLI утилите,
> хотя её использует библиотека, и логично было бы CLI утилите поставить
> зависимость на библиотеку. Буду обсуждать с сопровождающим foundry
> исправление.

Исправил: https://packages.altlinux.org/tasks/405214

(Ответ для Alexey Volkov на комментарий #5)
> (In reply to Semen Fomchenkov from comment #4)
> > Думаю ошибка в упаковке foundry, почему-то схема glib лежит в CLI утилите,
> > хотя её использует библиотека, и логично было бы CLI утилите поставить
> > зависимость на библиотеку. Буду обсуждать с сопровождающим foundry
> > исправление.
> 
> Исправил: https://packages.altlinux.org/tasks/405214

То есть теперь %_datadir/glib-2.0/schemas/
принадлежит не только libgio, но и libfoundry

Отличная работа мантейнера и его ментора.

(In reply to Yuri N. Sedunov from comment #6)
> (Ответ для Alexey Volkov на комментарий #5)
> > (In reply to Semen Fomchenkov from comment #4)
> > > Думаю ошибка в упаковке foundry, почему-то схема glib лежит в CLI утилите,
> > > хотя её использует библиотека, и логично было бы CLI утилите поставить
> > > зависимость на библиотеку. Буду обсуждать с сопровождающим foundry
> > > исправление.
> > 
> > Исправил: https://packages.altlinux.org/tasks/405214
> 
> То есть теперь %_datadir/glib-2.0/schemas/
> принадлежит не только libgio, но и libfoundry
> 
> Отличная работа мантейнера и его ментора.
Тут ошибка (к счастью, некритичная), а не отличная работа.

Алексей, не забудь поправить.

И это тоже.

%dir %_datadir/bash-completion
%dir %_datadir/bash-completion/completions
%_datadir/bash-completion/completions/%name

(In reply to Yuri N. Sedunov from comment #6)
> То есть теперь %_datadir/glib-2.0/schemas/
> принадлежит не только libgio, но и libfoundry

(In reply to Yuri N. Sedunov from comment #8)
> %dir %_datadir/bash-completion
> %dir %_datadir/bash-completion/completions
> %_datadir/bash-completion/completions/%name

И это исправил: https://packages.altlinux.org/en/tasks/405642/

А зачем вы так искалечили имя библиотеки? Эта галиматья из цифр в конце, она зачем в libfoundry-1_1. Вы видели эту чушь в именах гномовских библиотек? Кого вы хотите запутать?

(In reply to Yuri N. Sedunov from comment #10)
> А зачем вы так искалечили имя библиотеки? Эта галиматья из цифр в конце, она
> зачем в libfoundry-1_1. Вы видели эту чушь в именах гномовских библиотек?
> Кого вы хотите запутать?

В meson.build foundry не используется soversion или soname, там устанавливается api_version, который используется как version в сборке библиотеки.

meson.build:
...
foundry_shared = library('foundry-@0@'.format(api_version),
           dependencies: foundry_deps + [foundry_static_dep],
                 c_args: foundry_c_args,
                install: true,
  gnu_symbol_visibility: 'hidden',
                version: '@0@.0.0'.format(api_version),
        darwin_versions: '@0@.0'.format(api_version.to_int() + 1),
)
...

Поэтому было принято решение "склеить" soversion и api_version.

Но я сейчас перечитал документацию meson:
soversion: A string or integer specifying the soversion of this shared library, such as 0. On Linux and Windows this is used to set the soversion (or equivalent) in the filename. For example, if soversion is 4, a Windows DLL will be called foo-4.dll and one of the aliases of the Linux shared library would be libfoo.so.4. If this is not specified, the first part of version is used instead (see below). For example, if version is 3.6.0 and soversion is not defined, it is set to 3.

Так что в этом случае api_version это soversion, буду исправлять.

Руководствуйтесь здравым смыслом.
Не нужны цифры в имени подпакета с библиотекой, никакие.

(In reply to Yuri N. Sedunov from comment #12)
> Руководствуйтесь здравым смыслом.
> Не нужны цифры в имени подпакета с библиотекой, никакие.

Название библиотеки - libfoundry-1, и если применить Shared Libs Policy, то, в соответствии с:

https://www.altlinux.org/Shared_Libs_Policy#%D0%A3%D0%BF%D0%B0%D0%BA%D0%BE%D0%B2%D0%BA%D0%B0_%D0%B1%D0%B8%D0%B1%D0%BB%D0%B8%D0%BE%D1%82%D0%B5%D0%BA_(runtime_%D1%87%D0%B0%D1%81%D1%82%D1%8C)
* Название пакета: libfoo%abiversion
* Если имя библиотеки заканчивается на цифру, то используется подчёркивание: libfoo_%abiversion

небходимо еще добавить и _1. Но так как в этом проекте major_version == abi version == api version, то я предлагаю оставить только одну цифру, чтобы получилось libfoundry1. Вот в этом здравый смысл.
А если делать не зная это факта, то выходит libfoundry-1_1.

Совсем убрать цифры - нарушить Shared Libs Policy.
Прошу обратить внимание, что в этой политике не указана экосистема GNOME как исключения и тоже подпадает под политику.

Здравый смысл состоит в том, чтобы не применять Shared Libs Policy без особой нужды. В случае libfoundry такой нужды нет, и вряд ли будет, как и в подавляющем большинстве случаев упаковки библиотек.