Пакет libqt6-svg не включает в себя плагины, они в пакете qt6-svg. Если qt6-svg не установлен в приложениях не отображаются иконки. Проблема состоит в том, что у приложений не возникает зависимость на qt6-svg. Прописывать в спеке у каждого пакета с приложением на qt6 зависимость мне не кажется хорошей идеей. Вот libqt5-svg включает в себя плагины, и проблемы такой нет.
Я решил, что в Qt6 это будет хорошей идеей. Т.е. все qt6-пакеты так паковать буду. Упаковка "libqt5-чтото" и добавления туда "Provides: qt5-чтото" себя не оправдала. Зависимость всё равно ставили _вручную_ на "libqt5-чтото".
Прописывать в спеке у каждого пакета с приложением на qt6 эту зависимость хорошая идея? Не понимаю, при чём тут это: (Ответ для Sergey V Turchin на комментарий #1) > Упаковка "libqt5-чтото" и добавления туда "Provides: qt5-чтото" себя не > оправдала. Зависимость всё равно ставили _вручную_ на "libqt5-чтото". ? Почему не сделать qt6-svg пакет, который будет провайдить libqt6-svg? libqt6-svg по зависимостям устанавливается, а qt6-svg не устанавливается. Своим решением не исправлять проблему вынуждаешь ставить зависимость вручную на qt6-svg у всё возрастающего множества пакетов, зависящих от libqt6-svg.
(Ответ для Антон Мидюков на комментарий #2) > Почему не сделать qt6-svg пакет, который будет провайдить libqt6-svg? Потому, что на qt5-sql-sqlite никто зависимостей не ставил. Только что ходил и исправлял пакеты, которые наставили зависимстей на qt5-sql-sqlite(подпакет akonadi).
(Ответ для Sergey V Turchin на комментарий #3) > (Ответ для Антон Мидюков на комментарий #2) > > Почему не сделать qt6-svg пакет, который будет провайдить libqt6-svg? > Потому, что на qt5-sql-sqlite никто зависимостей не ставил. > Только что ходил и исправлял пакеты, которые наставили зависимстей на > qt5-sql-sqlite(подпакет akonadi). Я опять не понимаю связь одного с другим.
(Ответ для Sergey V Turchin на комментарий #3) > Только что ходил и исправлял пакеты, которые наставили зависимстей на > qt5-sql-sqlite(подпакет akonadi). Ошибся. qt5-sql-sqlite3 -- подпакет из akonadi.
(Ответ для Антон Мидюков на комментарий #4) > Я опять не понимаю связь одного с другим. То же самое, только имена другие.
Заново перепишу: Только что ходил и исправлял пакеты, которые наставили зависимостей на qt5-sql-sqlite3(подпакет akonadi), хотя надо qt5-sql-sqlite, который внутри libqt5-sql и провайдится им.
(Ответ для Sergey V Turchin на комментарий #7) > Заново перепишу: > Только что ходил и исправлял пакеты, которые наставили зависимостей на > qt5-sql-sqlite3(подпакет akonadi), хотя надо qt5-sql-sqlite, который внутри > libqt5-sql и провайдится им. А что есть пакет qt6-svg3? Есть другое решение проблемы, перенести плагины в libqt6-svg.
(Ответ для Антон Мидюков на комментарий #2) > Прописывать в спеке у каждого пакета с приложением на qt6 эту зависимость > хорошая идея? Таких хороших идей много(см. пакет jami) и я не могу их всех запихать в библиотеки. Иногда бывает даже так, что непонятно, к какой библиотеке их припаковать. P.S. Если QML, то можно взять пакет rpm-build-qml6, которым можно худо-бедно вычислить зависимости, но его лучше выключить перед конечной упаковкой и переписать вручную.
(Ответ для Антон Мидюков на комментарий #8) > А что есть пакет qt6-svg3? Приманка для мантейнера с головной болью.
(Ответ для Антон Мидюков на комментарий #8) > Есть другое решение проблемы, перенести плагины в libqt6-svg. Погоди! Я думал, что ты это и предлагал. Не! Как раз это я и не хочу. Тогда ещё раз сформулируй, пожалуйста.
(Ответ для Sergey V Turchin на комментарий #11) > (Ответ для Антон Мидюков на комментарий #8) > > Есть другое решение проблемы, перенести плагины в libqt6-svg. > Погоди! Я думал, что ты это и предлагал. > Не! Как раз это я и не хочу. > Тогда ещё раз сформулируй, пожалуйста. Тоже самое, но наоборот. Перенести библиотеки в qt6-svg и провайдить libqt6-svg пакетом qt6-svg.
(Ответ для Антон Мидюков на комментарий #12) > Перенести библиотеки в qt6-svg и провайдить libqt6-svg пакетом qt6-svg. Ой! До такого я бы и догадаться не смог. Это совсем не вариант.
(Ответ для Sergey V Turchin на комментарий #13) > (Ответ для Антон Мидюков на комментарий #12) > > Перенести библиотеки в qt6-svg и провайдить libqt6-svg пакетом qt6-svg. > Ой! До такого я бы и догадаться не смог. Это совсем не вариант. Тогда нужно научить rpmbuild находить зависимости на плагины. У приложений нет иконок, пока не установишь qt6-svg.
Я не вижу проблемы ставить зависимость на qt6-svg. Всё равно в большинстве случаев нужно искать, чего ещё не хватает пакету.
(Ответ для Sergey V Turchin на комментарий #15) > Я не вижу проблемы ставить зависимость на qt6-svg. Всё равно в большинстве > случаев нужно искать, чего ещё не хватает пакету. Например bug#47112 -- фиг куда запакуешь.
> Пакет libqt6-svg не включает в себя плагины, они в пакете qt6-svg. Мне кажется, тут стоило пояснить. Плагины из пакета qt6-svg -- это не плагины к libqt6-svg, это плагины к основному Qt 6, добавляющие в него поддержку иконок и просто картинок (QImage и все дела) в формате SVG. Это значит, что приложению не обязательно линковаться с libQt6Svg.so для того, чтобы эти пакеты были ему полезны. Я тут потыкал простейший пример, использующий QImage и QLabel, чтобы показать картинку из файла. $ ldd qimage | grep -i qt libQt6Widgets.so.6 => /usr/lib64/libQt6Widgets.so.6 (0x00007f6d71a00000) libQt6Gui.so.6 => /usr/lib64/libQt6Gui.so.6 (0x00007f6d71200000) libQt6Core.so.6 => /usr/lib64/libQt6Core.so.6 (0x00007f6d70c00000) libQt6DBus.so.6 => /usr/lib64/libQt6DBus.so.6 (0x00007f6d702d8000) Установка qt6-svg добавляет даже такому примеру (сверх)способность загружать и показывать картинки в формате svg. То есть, если в приложении есть иконки в SVG, то ему нужна зависимость на qt6-svg, а если нет, то не нужна; а линкуется ли в этом приложении что-то с libQt6Svg.so -- дело ортогональное. Так что, учитывая распространённость иконок в SVG, скорее нужна зависимость libqt6-gui (или где там теперь qimage) от qt6-svg, но это кажется слишком жестко.
Я ж говорю, qt6-imageformats -- пример, который просто так никуда не прилепишь и не припакуешь. В каком-нибудь kde6-runtime я конечно поставлю зависимость, как сейчас в kde5-runtime. И qt6-sql-* пихать все в libqt6-sql так же слишком жирно. P.S. Для qt5-sql-sqlite у меня есть исключение, но оно обернулось тем, что некоторые навешали зависимостей на неправильный qt5-sql-sqlite3(в сизифе удалил недавно).
(Ответ для Sergey V Turchin на комментарий #18) > Я ж говорю, qt6-imageformats -- пример, который просто так никуда не > прилепишь и не припакуешь. > > В каком-нибудь kde6-runtime я конечно поставлю зависимость, как сейчас в > kde5-runtime. > А почему бы не сделать qt6-runtime?
(Ответ для Антон Мидюков на комментарий #19) > А почему бы не сделать qt6-runtime? Разве что, отдельный пакет городить не хочется. Можно будет его присоседить к kde6-runtime.
Прошу убрать у libqt6-svg: Provides: %name = %EVR Думаю, из-за этого у пакетов и не возникает зависимость на qt6-svg. Кроме того из-за этого было бессмысленно делать у пакетов и: Requires: qt6-svg Так что и ошибку обойти никак нельзя сейчас.
Ой, блин. Ща.
(Ответ для Антон Мидюков на комментарий #19) > А почему бы не сделать qt6-runtime? Пока что я у qt6-imageformats поставил зависимость на qt6-svg.
qt6-svg-6.6.1-alt2 -> sisyphus: Wed Dec 06 2023 Sergey V Turchin <zerg@altlinux> 6.6.1-alt2 - fix provides (closes: 47318) Tue Dec 05 2023 Sergey V Turchin <zerg@altlinux> 6.6.1-alt1 - new version
В общем, я наигрался и в следующей версии буду запихивать всё подряд в пакеты с библиотеками. Нигде никаких изменений не потребуется.
