Bug#1013222: Private headers
Hi, On Tue, 17 Jan 2023 at 14:15, Rodney Dawes wrote: > > On Tue, 2023-01-17 at 13:43 -0300, Lisandro Damián Nicanor Pérez Meyer > wrote: > > Yes, but still not using Qt 6, so no need on our side to create more > > work for us while not yet there. It would be much much easier if they > > just used _stable_ API. And that's where we get back to upstream, > > plugins, etc. Create _stable_ API and everything goes smooth. > > Chicken, meet egg. Yes :-) > It would be much easier if Qt didn't require using private API to do > anything useful at this level. But here we are. Exactly. > Of course maliit isn't using Qt6 *yet* because in trying to do so, I > came across this issue already reported in Debian, which I use as my > main platform, and which has never presented such problem when > developing these projects before. Had the necessary private development > files already been available, we wouldn't even be having this > discussion, and I would already have maliit-framework building on Qt6 > (not least because I'm pretty sure I already did have it building as a > quick experiment, but when revisiting this yesterday, discovered the > private portion of qt6-wayland had been removed). I can offer you two solutions: 1. Come aboard maintaining Qt 6. Once you get a pair of Qt upgrades and you want to support private headers for the whole of the Qt 6 lifetime, you are welcome to add them and support them. 2. Break the chicken and egg issue by building your own Qt. You can use the debian packages as a base. Cheers, Lisandro. -- Lisandro Damián Nicanor Pérez Meyer https://perezmeyer.com.ar/
Bug#1013222: Private headers
On Tue, 2023-01-17 at 13:43 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > Yes, but still not using Qt 6, so no need on our side to create more > work for us while not yet there. It would be much much easier if they > just used _stable_ API. And that's where we get back to upstream, > plugins, etc. Create _stable_ API and everything goes smooth. Chicken, meet egg. It would be much easier if Qt didn't require using private API to do anything useful at this level. But here we are. Of course maliit isn't using Qt6 *yet* because in trying to do so, I came across this issue already reported in Debian, which I use as my main platform, and which has never presented such problem when developing these projects before. Had the necessary private development files already been available, we wouldn't even be having this discussion, and I would already have maliit-framework building on Qt6 (not least because I'm pretty sure I already did have it building as a quick experiment, but when revisiting this yesterday, discovered the private portion of qt6-wayland had been removed).
Bug#1013222: Private headers
On Tue, 17 Jan 2023 at 13:41, Rodney Dawes wrote: > > And to add to the point, currently the qt6-wayland package is broken in > Debian, even just trying to find it via CMake, because some of these > files have been removed. The following error is from simply checking > for the WaylandClient Qt component via: > > find_package(Qt6 6.2 REQUIRED COMPONENTS Core WaylandClient) Thanks! I just filed a bug for that. Public modules should not require private headers, not the first time we see this kind of issues.
Bug#1013222: Private headers
And to add to the point, currently the qt6-wayland package is broken in Debian, even just trying to find it via CMake, because some of these files have been removed. The following error is from simply checking for the WaylandClient Qt component via: find_package(Qt6 6.2 REQUIRED COMPONENTS Core WaylandClient) -- Could NOT find Qt6WaylandGlobalPrivate (missing: Qt6WaylandGlobalPrivate_DIR) CMake Warning at /usr/lib/x86_64-linux- gnu/cmake/Qt6/Qt6Config.cmake:167 (find_package): Found package configuration file: /usr/lib/x86_64-linux- gnu/cmake/Qt6WaylandClient/Qt6WaylandClientConfig.cmake but it set Qt6WaylandClient_FOUND to FALSE so package "Qt6WaylandClient" is considered to be NOT FOUND. Reason given by package: Qt6WaylandClient could not be found because dependency Qt6WaylandGlobalPrivate could not be found. Configuring with --debug-find-pkg=Qt6WaylandGlobalPrivate might reveal details why the package was not found. Configuring with -DQT_DEBUG_FIND_PACKAGE=ON will print the values of some of the path variables that find_package uses to try and find the package. Call Stack (most recent call first): CMakeLists.txt:24 (find_package) CMake Error at CMakeLists.txt:24 (find_package): Found package configuration file: /usr/lib/x86_64-linux-gnu/cmake/Qt6/Qt6Config.cmake but it set Qt6_FOUND to FALSE so package "Qt6" is considered to be NOT FOUND. Reason given by package: Failed to find required Qt component "WaylandClient". Expected Config file at "/usr/lib/x86_64-linux- gnu/cmake/Qt6WaylandClient/Qt6WaylandClientConfig.cmake" exists Configuring with --debug-find-pkg=Qt6WaylandClient might reveal details why the package was not found. Configuring with -DQT_DEBUG_FIND_PACKAGE=ON will print the values of some of the path variables that find_package uses to try and find the package. -- Configuring incomplete, errors occurred!
Bug#1013222: Private headers
Hi, On Tue, 17 Jan 2023 at 13:32, Rodney Dawes wrote: > > On Tue, 2023-01-17 at 13:03 -0300, Lisandro Damián Nicanor Pérez Meyer > wrote: > > Believe me I understand your frustration. But at the same time you > > don't know the pain it takes to maintain Qt as private headers get > > exposed. > > Actually, I do know. I work on Ubuntu Touch, where we maintained our > own Qt packages on top of Ubuntu. I've also worked on Plasma Mobile on > Manjaro, which ships the KDE patch collection on Qt5, which pulled in > some backported changes from Qt6, which broke ABI in the private API > side, causing much frustration. Being focused on mobile, there is also > the OpenGL vs GLES build issues. You do definitely know the landscape then :) > > Key Plasma packages are normally an exception, and Telegram desktop is > > definitely not a key plasma package. And again, yes, we would love to > > provide **everything**. But I sincerely do not see that happening > > until someone has proper Qt maintenance as his/her day job. > > If the situation of Qt/KDE in Debian is as bad as you say, can we not > reach out to Kubuntu/Neon devs to help out with it? Or maybe the Debian > UBports Team could help, given the heavy dependence on Qt which the > Lomiri stack has? The main Qt 5 maintainer is also Ubuntu's maintainer. From time to time people from Ubuntu try to help us, with various degrees of success, and here we are. Note that we do stress a lot what we think a Debian package should be, and sometimes that clashes with other distros expectations (and that's fine!). > I wasn't implying that telegram-desktop is a key > Plasma package, however, maliit-framework and maliit-keyboard are, I > would think. Yes, but still not using Qt 6, so no need on our side to create more work for us while not yet there. It would be much much easier if they just used _stable_ API. And that's where we get back to upstream, plugins, etc. Create _stable_ API and everything goes smooth. > > That being said the plan is to switch to Plasma with Qt 6 in Trixie > > (aka Debian 13), so I guess that after the freeze is over adding > > Qt-Wayland's private headers will be a must. > > But if nothing else in Debian would require these before the freeze, > why would it need to wait, since nothing would break as a result? No *key* package. As soon as we add private headers we gain non-key packages trying to use them, and thus more man power at the time of updating Qt. > Especially, given how anything that would require them is already > broken, so not having the private headers is already an issue (hence > this bug report). No, see above. -- Lisandro Damián Nicanor Pérez Meyer https://perezmeyer.com.ar/
Bug#1013222: Private headers
On Tue, 2023-01-17 at 13:03 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > Believe me I understand your frustration. But at the same time you > don't know the pain it takes to maintain Qt as private headers get > exposed. Actually, I do know. I work on Ubuntu Touch, where we maintained our own Qt packages on top of Ubuntu. I've also worked on Plasma Mobile on Manjaro, which ships the KDE patch collection on Qt5, which pulled in some backported changes from Qt6, which broke ABI in the private API side, causing much frustration. Being focused on mobile, there is also the OpenGL vs GLES build issues. > Key Plasma packages are normally an exception, and Telegram desktop is > definitely not a key plasma package. And again, yes, we would love to > provide **everything**. But I sincerely do not see that happening > until someone has proper Qt maintenance as his/her day job. If the situation of Qt/KDE in Debian is as bad as you say, can we not reach out to Kubuntu/Neon devs to help out with it? Or maybe the Debian UBports Team could help, given the heavy dependence on Qt which the Lomiri stack has? I wasn't implying that telegram-desktop is a key Plasma package, however, maliit-framework and maliit-keyboard are, I would think. > That being said the plan is to switch to Plasma with Qt 6 in Trixie > (aka Debian 13), so I guess that after the freeze is over adding > Qt-Wayland's private headers will be a must. But if nothing else in Debian would require these before the freeze, why would it need to wait, since nothing would break as a result? Especially, given how anything that would require them is already broken, so not having the private headers is already an issue (hence this bug report).
Bug#1013222: Private headers
Hi! On Tue, 17 Jan 2023 at 01:38, Rodney Dawes wrote: > > On Mon, 2023-01-16 at 23:35 -0300, Lisandro Damián Nicanor Pérez Meyer > wrote: > > Maintaining Qt already takes a lot of time, adding private headers > > only makes things worse. So if you want to do porting and the headers > > are not yet there you will have to build Qt itself or fix the problem > > where it really belongs: upstream. > > Upstream? Where it's not a problem, because they ship and install the > private headers? Private headers are non stable API, and that's a problem. > No, this is an issue in Debian, because the headers are being > specifically excluded from packaging, rather than installed. Other > distributions provide these files without such politics. Why is it so > hard to maintain in Debian? The way Debian works (transitions) and man power. It is not politics, it's man power. > Fedora, OpenSUSE, Arch, etc… all have these > files available for installation and developing against. So, surely the > "maintenance burden" is not so high, right? Debian has britney to run > autopackage tests, specifically to prevent things breaking, no? Those > things still are going to break, when those files aren't provided, > since they can no longer build, no? That's actually the point: the maintenance burden **IS** high. Yes, even with britney testing stuff, we still need to manually build/trigger builds for all affected packages (all that use private headers), file bugs, cross fingers that maintainers will fix them or provide fix ourselves. Else we can't ask for a transition slot. Qt is currently (and has been mostly during all these years) maintained by one or two people. Currently Qt5 is maintained by Dmitry and Qt 6 by Patrick, and some people helping whenever possible (like me, nowadays). It's a huge task, one that would be better served by someone dedicated to it, which is not our case. So yes: man power IS an issue, and private headers only adds more man power requirements. Believe me I understand your frustration. But at the same time you don't know the pain it takes to maintain Qt as private headers get exposed. > There is nothing speculative here. The files are required to build many > things against Qt, regardless of whether it is version 5 or 6. > > Leaving the files out, only makes it harder for anyone to rely on > distribution provided packages. These are necessary for shipping KDE > Plasma 6, and many other things, in Debian. Key Plasma packages are normally an exception, and Telegram desktop is definitely not a key plasma package. And again, yes, we would love to provide **everything**. But I sincerely do not see that happening until someone has proper Qt maintenance as his/her day job. That being said the plan is to switch to Plasma with Qt 6 in Trixie (aka Debian 13), so I guess that after the freeze is over adding Qt-Wayland's private headers will be a must. -- Lisandro Damián Nicanor Pérez Meyer https://perezmeyer.com.ar/
Bug#1013222: Private headers
On Mon, 2023-01-16 at 23:35 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > Maintaining Qt already takes a lot of time, adding private headers > only makes things worse. So if you want to do porting and the headers > are not yet there you will have to build Qt itself or fix the problem > where it really belongs: upstream. Upstream? Where it's not a problem, because they ship and install the private headers? No, this is an issue in Debian, because the headers are being specifically excluded from packaging, rather than installed. Other distributions provide these files without such politics. Why is it so hard to maintain in Debian? Fedora, OpenSUSE, Arch, etc… all have these files available for installation and developing against. So, surely the "maintenance burden" is not so high, right? Debian has britney to run autopackage tests, specifically to prevent things breaking, no? Those things still are going to break, when those files aren't provided, since they can no longer build, no? There is nothing speculative here. The files are required to build many things against Qt, regardless of whether it is version 5 or 6. Leaving the files out, only makes it harder for anyone to rely on distribution provided packages. These are necessary for shipping KDE Plasma 6, and many other things, in Debian.
Bug#1013222: Private headers
Hi! El lun, 16 de ene. de 2023 21:59, Rodney Dawes escribió: > On Mon, 2023-01-16 at 21:35 -0300, Lisandro Damián Nicanor Pérez Meyer > wrote: > > Hi > > > > Private packages have only been created when required for other Qt > > submodules or key plasma packages, no more. > > They are required for key plasma packages here, as well. It is > necessary to use these private headers to be able to write plugins to > Qt itself, such as for providing support for additional wayland > protocols in Qt, and to provide input method support on Wayland using > Qt API. I found this issue as I was getting build errors on doing some > work to port the wayland code in maliit-framework to Qt6. You will probably need to build qt yourself to do that in the meantime. > > > That's because kwin required those headers. As soon as kwin switches > > to Qt6 we will know if we need to make them available. > > If kwin is also using them, then you can be assured they will still be > needed, as very little has changed in QtWayland in 6.x from 5.x. As I > have found, they are still needed for the on-screen keyboard support. > Then when time comes the packages will be added > And no, existing private headers are not free, it is a real pain > > because they normally just make transitions more complicated. > > > > Ideally people should work with Qt upstream in order to avoid > > requiring private headers. > > Most of these needs are long standing issues which I'm sure Qt upstream > is well aware of. Third party style plugins for example is a well known > case where one must use private API, and it is still the case. > Migrating things from private to public API is never a simple task, and > even if we could get it done, it would likely take years to get there. > I know, I have been complaining about that for over a decade now. With upstream :-) Maintaining Qt already takes a lot of time, adding private headers only makes things worse. So if you want to do porting and the headers are not yet there you will have to build Qt itself or fix the problem where it really belongs: upstream.
Bug#1013222: Private headers
On Mon, 2023-01-16 at 21:35 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > Hi > > Private packages have only been created when required for other Qt > submodules or key plasma packages, no more. They are required for key plasma packages here, as well. It is necessary to use these private headers to be able to write plugins to Qt itself, such as for providing support for additional wayland protocols in Qt, and to provide input method support on Wayland using Qt API. I found this issue as I was getting build errors on doing some work to port the wayland code in maliit-framework to Qt6. > > That's because kwin required those headers. As soon as kwin switches > to Qt6 we will know if we need to make them available. If kwin is also using them, then you can be assured they will still be needed, as very little has changed in QtWayland in 6.x from 5.x. As I have found, they are still needed for the on-screen keyboard support. > And no, existing private headers are not free, it is a real pain > because they normally just make transitions more complicated. > > Ideally people should work with Qt upstream in order to avoid > requiring private headers. Most of these needs are long standing issues which I'm sure Qt upstream is well aware of. Third party style plugins for example is a well known case where one must use private API, and it is still the case. Migrating things from private to public API is never a simple task, and even if we could get it done, it would likely take years to get there.
Bug#1013222: Private headers
Hi El lun, 16 de ene. de 2023 19:03, Rodney Dawes escribió: > On Mon, 25 Jul 2022 16:29:28 -0300 =?UTF- > 8?Q?Lisandro_Dami=C3=A1n_Nicanor_P=C3=A9rez_Meyer?= > wrote: > > Hi! > > > > I would really love to know why Telegram developers require so many > > private headers from Qt. They shouldn't be using them at all, and if > > they really require some private part they need to work with upstream > > to make it public API. > > This isn't only an issue for Telegram. Many projects require private > headers for various reasons, because developing plugins to Qt itself is > necessary to improve the system. The Qt packages have a long history of > including `-private-dev` packages for the various components which > provide private API that may be necessary to use in certain situations. > Private packages have only been created when required for other Qt submodules or key plasma packages, no more. > > There is no reason for that to stop happening with Qt 6.x. Qt6 is following the same rule. Believe me, I have been involved in Qt packaging since Qt4 :-) Especially > given the upstream source is installing them during the build. The > qtwayland5-private-dev package is available in Debian, and so should a > qt6-wayland-private-dev package be made available containing the > includes, cmake files, libraries, etc… necessary to use the QtWayland > private API with Qt6. That's because kwin required those headers. As soon as kwin switches to Qt6 we will know if we need to make them available. And no, existing private headers are not free, it is a real pain because they normally just make transitions more complicated. Ideally people should work with Qt upstream in order to avoid requiring private headers.
Bug#1013222: Private headers
On Mon, 25 Jul 2022 16:29:28 -0300 =?UTF- 8?Q?Lisandro_Dami=C3=A1n_Nicanor_P=C3=A9rez_Meyer?= wrote: > Hi! > > I would really love to know why Telegram developers require so many > private headers from Qt. They shouldn't be using them at all, and if > they really require some private part they need to work with upstream > to make it public API. This isn't only an issue for Telegram. Many projects require private headers for various reasons, because developing plugins to Qt itself is necessary to improve the system. The Qt packages have a long history of including `-private-dev` packages for the various components which provide private API that may be necessary to use in certain situations. There is no reason for that to stop happening with Qt 6.x. Especially given the upstream source is installing them during the build. The qtwayland5-private-dev package is available in Debian, and so should a qt6-wayland-private-dev package be made available containing the includes, cmake files, libraries, etc… necessary to use the QtWayland private API with Qt6.
Bug#1013222: Private headers
Hi! I would really love to know why Telegram developers require so many private headers from Qt. They shouldn't be using them at all, and if they really require some private part they need to work with upstream to make it public API. -- Lisandro Damián Nicanor Pérez Meyer https://perezmeyer.com.ar/