49665 2024-03-12 15:26:05 +0300 devel-файлы в основном пакете, но не упакованы в devel-подпакет 2024-05-31 15:35:33 +0300 1 1 4 Development Sisyphus alterator-roles unstable x86_64 Linux NEW P5 normal --- 1 zerg svn17 nbr rider svn17 qa-sisyphus oldest_to_newest 242887 0 zerg 2024-03-12 15:26:05 +0300 xml-описание dbus-интерфейса должно быть в devel-подпакете. 242889 1 zerg 2024-03-12 15:28:07 +0300 Если оно не предназначено для использования за пределами пакета, то паковать этот файл вообще не надо. 242929 2 svn17 2024-03-13 12:55:48 +0300 (Ответ для 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 242930 3 svn17 2024-03-13 12:57:24 +0300 (Ответ для Sergey V Turchin на комментарий #1) > Если оно не предназначено для использования за пределами пакета, то паковать > этот файл вообще не надо. Разве нельзя хранить интроспекцию в отдельном файле? Или тут про другое? 242932 4 zerg 2024-03-13 13:22:28 +0300 (Ответ для Иван Савин на комментарий #2) > У других не в devel: Всё баги. 242934 5 zerg 2024-03-13 13:24:09 +0300 (Ответ для Иван Савин на комментарий #3) > Разве нельзя хранить интроспекцию в отдельном файле? Или тут про другое? Это как заголовочный файл, т.е. описание API. По нему все генерируют код в нужное представление. qdbusxml2cpp, например. 242941 6 zerg 2024-03-13 13:33:14 +0300 (Ответ для Иван Савин на комментарий #2) > У других не в devel: Развесил всем. 243000 7 svn17 2024-03-14 16:06:40 +0300 (Ответ для Sergey V Turchin на комментарий #5) > Это как заголовочный файл, т.е. описание API. > По нему все генерируют код в нужное представление. qdbusxml2cpp, например. Между заголовочными файлами и файлами интерфейсов d-bus есть разница. Первые используются во время сборки, а вторые во время выполнения, хотя на основе этих xml файлов можно генерировать код (например для proxy объектов). Это xml описание интерфейса, который будет реализован службой на d-bus и, по этому описанию, конечно, можно генерировать код для работы с этой службой. 243014 8 zerg 2024-03-15 10:14:21 +0300 (Ответ для Иван Савин на комментарий #7) > Между заголовочными файлами и файлами интерфейсов d-bus есть разница. Первые > используются во время сборки, а вторые во время выполнения Чушь. Во время сборки. Только. https://dbus.freedesktop.org/doc/dbus-api-design.html#code-generation 243024 9 zerg 2024-03-15 12:33:27 +0300 (Ответ для Sergey V Turchin на комментарий #8) > Чушь. Во время сборки. Только. Не, вру. "may be introspected at runtime" https://dbus.freedesktop.org/doc/dbus-specification.html#introspection-format Это значит, что файл должен быть и в devel и в не-devel пакетах(так уже можно), т.к. требовать для сборки основной пакет некрасиво и нерационально. 243039 10 svn17 2024-03-15 13:33:48 +0300 (Ответ для 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 243040 11 zerg 2024-03-15 13:37:51 +0300 (Ответ для Иван Савин на комментарий #10) > Заставлять этих разработчиков в devel эту xml укладывать? В зависимости от. > Нет, это на усмотрение разработчика. Если разработчик усмотрел использование этого API за пределами пакета, то xml-файл должен быть упакован мантейнером в devel-подпакет. Если нет, то можно вообще не паковать. 243041 12 zerg 2024-03-15 13:40:35 +0300 (Ответ для Иван Савин на комментарий #10) > https://dbus.freedesktop.org/doc/dbus-api-design.html#apis Этого мало. API обязан быть не какой-то подачкой, а стабильным и версионированым. 243044 13 svn17 2024-03-15 14:03:45 +0300 (Ответ для Sergey V Turchin на комментарий #11) > (Ответ для Иван Савин на комментарий #10) > Если разработчик усмотрел использование этого API за пределами пакета, то > xml-файл должен быть упакован мантейнером в devel-подпакет. Если нет, то > можно вообще не паковать. Это интерфейс для dbus, конечно он используется за пределами пакета. А файла, как сказано выше, может не быть. И это "a valid approach": https://dbus.freedesktop.org/doc/dbus-api-design.html#apis 243045 14 zerg 2024-03-15 14:12:49 +0300 (Ответ для Иван Савин на комментарий #13) > файла, как сказано выше, может не быть. > И это "a valid approach": > https://dbus.freedesktop.org/doc/dbus-api-design.html#apis Если разработчик задумал это как I, а не как API, то да, соглашусь. 243047 15 svn17 2024-03-15 14:35:33 +0300 (Ответ для 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"! 243050 16 svn17 2024-03-15 14:37:05 +0300 (Ответ для Иван Савин на комментарий #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 243055 17 zerg 2024-03-15 15:06:06 +0300 (Ответ для Иван Савин на комментарий #16) > > "to define the API"! > https://dbus.freedesktop.org/doc/dbus-api-design.html#apis Такая подачка не может быть API по определению, т.к. может меняться динамически. API должно быть конкретно определено. Вопрос, где? P.S. Я уже встречал на FDO спецификации, которые разработчики glib и qt трактуют так, как им больше хочется, потому, что остальные все условия изменились и архитектура, описанная в спецификации больше реально не работает и осталась только формально. 243060 18 zerg 2024-03-15 15:19:05 +0300 (Ответ для Иван Савин на комментарий #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 Ну или перефразирую. Для того, чтоб скомпилировать программу, использующий этот интерфейс, нужно установить сервис, правильно сконфигурировать его, запустить, выдернуть интроспекцию и уже с ней собрать программу. Вы полагаете, что найдётся хоть кто-то, кто посчитает это вменяемым? 243066 19 svn17 2024-03-15 16:03:07 +0300 (Ответ для Sergey V Turchin на комментарий #18) > (Ответ для Иван Савин на комментарий #16) > Для того, чтоб скомпилировать программу, использующий этот интерфейс, нужно > установить сервис, правильно сконфигурировать его, запустить, выдернуть > интроспекцию и уже с ней собрать программу. Вы полагаете, что найдётся хоть > кто-то, кто посчитает это вменяемым? Это нужно сделать если вы хотите генерировать код на основе интроспекции. Чтобы компилировать это не нужно делать. 243067 20 zerg 2024-03-15 16:12:36 +0300 (Ответ для Иван Савин на комментарий #19) > Это нужно сделать если вы хотите генерировать код на основе интроспекции. Этот код нужно компилировать > Чтобы компилировать это не нужно делать. , а для этого нужно где-то взять интроспекцию. P.S. И взять не фиг знает что, а API. 243068 21 svn17 2024-03-15 16:25:26 +0300 (Ответ для Sergey V Turchin на комментарий #20) > (Ответ для Иван Савин на комментарий #19) > > Это нужно сделать если вы хотите генерировать код на основе интроспекции. > Этот код нужно компилировать > > > Чтобы компилировать это не нужно делать. > , а для этого нужно где-то взять интроспекцию. Для компиляции? Зачем? 243069 22 zerg 2024-03-15 16:27:11 +0300 (Ответ для Иван Савин на комментарий #21) > > > Это нужно сделать если вы хотите генерировать код на основе интроспекции. > > Этот код нужно компилировать > > > Чтобы компилировать это не нужно делать. > > , а для этого нужно где-то взять интроспекцию. > Для компиляции? Зачем? https://dbus.freedesktop.org/doc/dbus-api-design.html#code-generation 243070 23 nbr 2024-03-15 16:31:01 +0300 Класть такое содержимое в <packetname>-dbusxml.1.0.1.alt1.rpm ? Тогда его можно будет убирать из образов, в которых требуется полное выбрасывание среды разработки, а для менее строгих применений, в которых, скажем, возможно создание интроспекции на питоне в рантайме - оставлять. 243071 24 zerg 2024-03-15 16:42:48 +0300 (Ответ для nbr на комментарий #23) > Класть такое содержимое в > <packetname>-dbusxml.1.0.1.alt1.rpm Если предполагается кодогенерация на лету, то да. И зависимость на него в devel-пакете. Но, сейчас вроде можно один файл в разные подпакеты паковать, а это проще, чем делать отдельный подпакет. 243085 25 svn17 2024-03-16 10:08:19 +0300 (Ответ для 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 тогда берётся из документации. 243086 26 rider 2024-03-16 10:35:26 +0300 (Ответ для Sergey V Turchin на комментарий #24) > (Ответ для nbr на комментарий #23) > > Класть такое содержимое в > > <packetname>-dbusxml.1.0.1.alt1.rpm > Если предполагается кодогенерация на лету, то да. И зависимость на него в > devel-пакете. Но, сейчас вроде можно один файл в разные подпакеты паковать, > а это проще, чем делать отдельный подпакет. devel пакет же может (и должен) зависить от библиотеки. Честно говоря вообще не понял что вы спорите. Если каким-то приложениям на python нужен этот файл, то он должен лежать не в devel пакете, если он не используется ни для чего, кроме сборки - то лучше переложить в devel 243121 27 zerg 2024-03-18 09:56:37 +0300 (Ответ для Anton Farygin на комментарий #26) > Если каким-то приложениям на python нужен этот файл, то он должен лежать не > в devel пакете, если он не используется ни для чего, кроме сборки - то лучше > переложить в devel Да, т.к. тащить основной пакет для сборки некрасиво. Дополню: Если возможно использование и там и там, то надо паковать в оба. Если нужен только внутри своих подпакетов, то вообще не паковать. 243122 28 zerg 2024-03-18 09:57:37 +0300 (Ответ для Anton Farygin на комментарий #26) > devel пакет же может (и должен) зависить от библиотеки. Если там кроме cmake-файлов и xml-описания ничего нет, то нет. 243123 29 zerg 2024-03-18 10:19:36 +0300 (Ответ для Anton Farygin на комментарий #26) > Честно говоря вообще не понял что вы спорите. Лично я потому, что возникло подозрение, что у нового Alterator не будет API как такового вообще, а то, что будет, нельзя будет называть API, от которого будет только I. (Ответ для Иван Савин на комментарий #25) > API тогда берётся из документации. Ну, разве что, будет задокументировано. Но, в это ещё слабее верится. 243142 30 svn17 2024-03-18 14:58:52 +0300 (Ответ для Sergey V Turchin на комментарий #29) > (Ответ для Anton Farygin на комментарий #26) > > Честно говоря вообще не понял что вы спорите. > Лично я потому, что возникло подозрение, что у нового Alterator не будет API > как такового вообще, а то, что будет, нельзя будет называть API, от которого > будет только I. Если так, то багу надо закрывать, так как это не баг. Причём тут новый альтератор? Он не хранит свою интроспекцию в файле в dbus-1/interfaces/. Она в коде, а это "a valid approach". Также как и множество других сервисов, например, вышеупомянутый polkit agent. > (Ответ для Иван Савин на комментарий #25) > > API тогда берётся из документации. > Ну, разве что, будет задокументировано. Но, в это ещё слабее верится. Спорить про веру вообще бессмысленно. 243143 31 zerg 2024-03-18 15:08:34 +0300 (Ответ для Иван Савин на комментарий #30) > Если так, то багу надо закрывать, так как это не баг. Этот баг не надо, т.к. он не исправлен, а новый про Alterator создам отдельно, когда потребуется. 247068 32 zerg 2024-05-31 15:35:33 +0300 Повторю на всякий ещё раз суть: для использования qdbusxml2cpp понадобится установить НЕ-devel пакет.