xml-описание dbus-интерфейса должно быть в devel-подпакете.
Если оно не предназначено для использования за пределами пакета, то паковать этот файл вообще не надо.
(Ответ для Sergey V Turchin на комментарий #0) > xml-описание dbus-интерфейса должно быть в devel-подпакете. У других не в devel: #rpm -qf /usr/share/dbus-1/interfaces/*.xml malcontent-0.10.3-alt1.x86_64 malcontent-0.10.3-alt1.x86_64 malcontent-0.10.3-alt1.x86_64 system-config-printer-lib-1.5.17-alt1.x86_64 colord-1.4.6-alt1.x86_64 colord-1.4.6-alt1.x86_64 colord-1.4.6-alt1.x86_64 colord-1.4.6-alt1.x86_64 colord-1.4.6-alt1.x86_64 lightdm-1.30.0-alt24.x86_64 fwupd-1.9.13-alt1.x86_64 alterator-update-kernel-1.4-alt2.x86_64
(Ответ для Sergey V Turchin на комментарий #1) > Если оно не предназначено для использования за пределами пакета, то паковать > этот файл вообще не надо. Разве нельзя хранить интроспекцию в отдельном файле? Или тут про другое?
(Ответ для Иван Савин на комментарий #2) > У других не в devel: Всё баги.
(Ответ для Иван Савин на комментарий #3) > Разве нельзя хранить интроспекцию в отдельном файле? Или тут про другое? Это как заголовочный файл, т.е. описание API. По нему все генерируют код в нужное представление. qdbusxml2cpp, например.
(Ответ для Иван Савин на комментарий #2) > У других не в devel: Развесил всем.
(Ответ для Sergey V Turchin на комментарий #5) > Это как заголовочный файл, т.е. описание API. > По нему все генерируют код в нужное представление. qdbusxml2cpp, например. Между заголовочными файлами и файлами интерфейсов d-bus есть разница. Первые используются во время сборки, а вторые во время выполнения, хотя на основе этих xml файлов можно генерировать код (например для proxy объектов). Это xml описание интерфейса, который будет реализован службой на d-bus и, по этому описанию, конечно, можно генерировать код для работы с этой службой.
(Ответ для Иван Савин на комментарий #7) > Между заголовочными файлами и файлами интерфейсов d-bus есть разница. Первые > используются во время сборки, а вторые во время выполнения Чушь. Во время сборки. Только. https://dbus.freedesktop.org/doc/dbus-api-design.html#code-generation
(Ответ для Sergey V Turchin на комментарий #8) > Чушь. Во время сборки. Только. Не, вру. "may be introspected at runtime" https://dbus.freedesktop.org/doc/dbus-specification.html#introspection-format Это значит, что файл должен быть и в devel и в не-devel пакетах(так уже можно), т.к. требовать для сборки основной пакет некрасиво и нерационально.
(Ответ для Sergey V Turchin на комментарий #9) > (Ответ для Sergey V Turchin на комментарий #8) > Это значит, что файл должен быть и в devel и в не-devel пакетах(так уже > можно), т.к. требовать для сборки основной пакет некрасиво и нерационально. Файла вообще может не быть, xml может быть в коде "гвоздями прибита". Сколько файлов в dbus-1/interfaces и сколько сервисов с интерфейсом на dbus установлено? Заставлять этих разработчиков в devel эту xml укладывать? Нет, это на усмотрение разработчика. https://dbus.freedesktop.org/doc/dbus-api-design.html#apis
(Ответ для Иван Савин на комментарий #10) > Заставлять этих разработчиков в devel эту xml укладывать? В зависимости от. > Нет, это на усмотрение разработчика. Если разработчик усмотрел использование этого API за пределами пакета, то xml-файл должен быть упакован мантейнером в devel-подпакет. Если нет, то можно вообще не паковать.
(Ответ для Иван Савин на комментарий #10) > https://dbus.freedesktop.org/doc/dbus-api-design.html#apis Этого мало. API обязан быть не какой-то подачкой, а стабильным и версионированым.
(Ответ для Sergey V Turchin на комментарий #11) > (Ответ для Иван Савин на комментарий #10) > Если разработчик усмотрел использование этого API за пределами пакета, то > xml-файл должен быть упакован мантейнером в devel-подпакет. Если нет, то > можно вообще не паковать. Это интерфейс для dbus, конечно он используется за пределами пакета. А файла, как сказано выше, может не быть. И это "a valid approach": https://dbus.freedesktop.org/doc/dbus-api-design.html#apis
(Ответ для Иван Савин на комментарий #13) > файла, как сказано выше, может не быть. > И это "a valid approach": > https://dbus.freedesktop.org/doc/dbus-api-design.html#apis Если разработчик задумал это как I, а не как API, то да, соглашусь.
(Ответ для Sergey V Turchin на комментарий #14) > (Ответ для Иван Савин на комментарий #13) > Если разработчик задумал это как I, а не как API, то да, соглашусь. "Some projects, however, choose to define the API in the code for the service, and to export XML interface files from the running service using D-Bus introspection." "to define the API"!
(Ответ для Иван Савин на комментарий #15) > (Ответ для Sergey V Turchin на комментарий #14) > > (Ответ для Иван Савин на комментарий #13) > > Если разработчик задумал это как I, а не как API, то да, соглашусь. > > "Some projects, however, choose to define the API in the code for the > service, and to export XML interface files from the running service using > D-Bus introspection." > > "to define the API"! https://dbus.freedesktop.org/doc/dbus-api-design.html#apis
(Ответ для Иван Савин на комментарий #16) > > "to define the API"! > https://dbus.freedesktop.org/doc/dbus-api-design.html#apis Такая подачка не может быть API по определению, т.к. может меняться динамически. API должно быть конкретно определено. Вопрос, где? P.S. Я уже встречал на FDO спецификации, которые разработчики glib и qt трактуют так, как им больше хочется, потому, что остальные все условия изменились и архитектура, описанная в спецификации больше реально не работает и осталась только формально.
(Ответ для Иван Савин на комментарий #16) > > "Some projects, however, choose to define the API in the code for the > > service, and to export XML interface files from the running service using > > D-Bus introspection." > > "to define the API"! > https://dbus.freedesktop.org/doc/dbus-api-design.html#apis Ну или перефразирую. Для того, чтоб скомпилировать программу, использующий этот интерфейс, нужно установить сервис, правильно сконфигурировать его, запустить, выдернуть интроспекцию и уже с ней собрать программу. Вы полагаете, что найдётся хоть кто-то, кто посчитает это вменяемым?
(Ответ для Sergey V Turchin на комментарий #18) > (Ответ для Иван Савин на комментарий #16) > Для того, чтоб скомпилировать программу, использующий этот интерфейс, нужно > установить сервис, правильно сконфигурировать его, запустить, выдернуть > интроспекцию и уже с ней собрать программу. Вы полагаете, что найдётся хоть > кто-то, кто посчитает это вменяемым? Это нужно сделать если вы хотите генерировать код на основе интроспекции. Чтобы компилировать это не нужно делать.
(Ответ для Иван Савин на комментарий #19) > Это нужно сделать если вы хотите генерировать код на основе интроспекции. Этот код нужно компилировать > Чтобы компилировать это не нужно делать. , а для этого нужно где-то взять интроспекцию. P.S. И взять не фиг знает что, а API.
(Ответ для Sergey V Turchin на комментарий #20) > (Ответ для Иван Савин на комментарий #19) > > Это нужно сделать если вы хотите генерировать код на основе интроспекции. > Этот код нужно компилировать > > > Чтобы компилировать это не нужно делать. > , а для этого нужно где-то взять интроспекцию. Для компиляции? Зачем?
(Ответ для Иван Савин на комментарий #21) > > > Это нужно сделать если вы хотите генерировать код на основе интроспекции. > > Этот код нужно компилировать > > > Чтобы компилировать это не нужно делать. > > , а для этого нужно где-то взять интроспекцию. > Для компиляции? Зачем? https://dbus.freedesktop.org/doc/dbus-api-design.html#code-generation
Класть такое содержимое в <packetname>-dbusxml.1.0.1.alt1.rpm ? Тогда его можно будет убирать из образов, в которых требуется полное выбрасывание среды разработки, а для менее строгих применений, в которых, скажем, возможно создание интроспекции на питоне в рантайме - оставлять.
(Ответ для nbr на комментарий #23) > Класть такое содержимое в > <packetname>-dbusxml.1.0.1.alt1.rpm Если предполагается кодогенерация на лету, то да. И зависимость на него в devel-пакете. Но, сейчас вроде можно один файл в разные подпакеты паковать, а это проще, чем делать отдельный подпакет.
(Ответ для Sergey V Turchin на комментарий #18) > (Ответ для Иван Савин на комментарий #16) > > > "Some projects, however, choose to define the API in the code for the > > > service, and to export XML interface files from the running service using > > > D-Bus introspection." > > > "to define the API"! > > https://dbus.freedesktop.org/doc/dbus-api-design.html#apis > Ну или перефразирую. > Для того, чтоб скомпилировать программу, использующий этот интерфейс, нужно > установить сервис, правильно сконфигурировать его, запустить, выдернуть > интроспекцию и уже с ней собрать программу. Вы полагаете, что найдётся хоть > кто-то, кто посчитает это вменяемым? И даже этой опции может не быть. Интерфейс org.freedesktop.DBus.Introspectable может быть не реализован на объекте. Как пример - polkit agent. API тогда берётся из документации.
(Ответ для Sergey V Turchin на комментарий #24) > (Ответ для nbr на комментарий #23) > > Класть такое содержимое в > > <packetname>-dbusxml.1.0.1.alt1.rpm > Если предполагается кодогенерация на лету, то да. И зависимость на него в > devel-пакете. Но, сейчас вроде можно один файл в разные подпакеты паковать, > а это проще, чем делать отдельный подпакет. devel пакет же может (и должен) зависить от библиотеки. Честно говоря вообще не понял что вы спорите. Если каким-то приложениям на python нужен этот файл, то он должен лежать не в devel пакете, если он не используется ни для чего, кроме сборки - то лучше переложить в devel
(Ответ для Anton Farygin на комментарий #26) > Если каким-то приложениям на python нужен этот файл, то он должен лежать не > в devel пакете, если он не используется ни для чего, кроме сборки - то лучше > переложить в devel Да, т.к. тащить основной пакет для сборки некрасиво. Дополню: Если возможно использование и там и там, то надо паковать в оба. Если нужен только внутри своих подпакетов, то вообще не паковать.
(Ответ для Anton Farygin на комментарий #26) > devel пакет же может (и должен) зависить от библиотеки. Если там кроме cmake-файлов и xml-описания ничего нет, то нет.
(Ответ для Anton Farygin на комментарий #26) > Честно говоря вообще не понял что вы спорите. Лично я потому, что возникло подозрение, что у нового Alterator не будет API как такового вообще, а то, что будет, нельзя будет называть API, от которого будет только I. (Ответ для Иван Савин на комментарий #25) > API тогда берётся из документации. Ну, разве что, будет задокументировано. Но, в это ещё слабее верится.
(Ответ для Sergey V Turchin на комментарий #29) > (Ответ для Anton Farygin на комментарий #26) > > Честно говоря вообще не понял что вы спорите. > Лично я потому, что возникло подозрение, что у нового Alterator не будет API > как такового вообще, а то, что будет, нельзя будет называть API, от которого > будет только I. Если так, то багу надо закрывать, так как это не баг. Причём тут новый альтератор? Он не хранит свою интроспекцию в файле в dbus-1/interfaces/. Она в коде, а это "a valid approach". Также как и множество других сервисов, например, вышеупомянутый polkit agent. > (Ответ для Иван Савин на комментарий #25) > > API тогда берётся из документации. > Ну, разве что, будет задокументировано. Но, в это ещё слабее верится. Спорить про веру вообще бессмысленно.
(Ответ для Иван Савин на комментарий #30) > Если так, то багу надо закрывать, так как это не баг. Этот баг не надо, т.к. он не исправлен, а новый про Alterator создам отдельно, когда потребуется.
