Summary: | Пакет libqt6-svg не включает в себя плагины | ||
---|---|---|---|
Product: | Sisyphus | Reporter: | Антон Мидюков <antohami> |
Component: | libqt6-svg | Assignee: | Sergey V Turchin <zerg> |
Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
Severity: | normal | ||
Priority: | P5 | CC: | arbars, iv, zerg |
Version: | unstable | ||
Hardware: | all | ||
OS: | Linux |
Description
Антон Мидюков
2023-08-22 14:25:06 MSK
Я решил, что в 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 |