Bug#958521: qtquickcontrols2-5-dev: Private headers missing
Package: qtquickcontrols2-5-dev Version: 5.11.3+dfsg-2 Severity: important Tags: patch Dear Maintainer, the private headers and modules are missing from this development package for both modules quickcontrols2 and quicktemplates2. These files are important if the user wants to compile a project that contains either of these module dependencies: QT += quickcontrols2-private quicktemplates2-private Currently, such a compile fails as the *.pri files (not to mention the header files) are missing. Note that while compiling against Qt private modules may not be good form, it is allowed and I would expect this to be possible with Debian-provided Qt modules (it is with the qtbase ones). One can argue about creating an extra package just for the private development files, but in the attached patch I opted to include the files together with the public ones. Thank you, Olaf Mandel -- System Information: Debian Release: 10.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages qtquickcontrols2-5-dev depends on: ii libqt5quickcontrols2-5 5.11.3+dfsg-2 ii libqt5quicktemplates2-5 5.11.3+dfsg-2 qtquickcontrols2-5-dev recommends no packages. qtquickcontrols2-5-dev suggests no packages. -- no debconf information --- a/debian/qtquickcontrols2-5-dev.install +++ b/debian/qtquickcontrols2-5-dev.install @@ -6,11 +6,129 @@ usr/include/*/qt5/QtQuickControls2/qtquickcontrols2-config.h usr/include/*/qt5/QtQuickControls2/qtquickcontrols2global.h usr/include/*/qt5/QtQuickControls2/qtquickcontrols2version.h +usr/include/*/qt5/QtQuickControls2/*/QtQuickControls2/private/qtquickcontrols2-config_p.h +usr/include/*/qt5/QtQuickControls2/*/QtQuickControls2/private/qquicktumblerview_p.h +usr/include/*/qt5/QtQuickControls2/*/QtQuickControls2/private/qquicktheme_p.h +usr/include/*/qt5/QtQuickControls2/*/QtQuickControls2/private/qquickcolorimage_p.h +usr/include/*/qt5/QtQuickControls2/*/QtQuickControls2/private/qquickplaceholdertext_p.h +usr/include/*/qt5/QtQuickControls2/*/QtQuickControls2/private/qquickmnemoniclabel_p.h +usr/include/*/qt5/QtQuickControls2/*/QtQuickControls2/private/qquickiconlabel_p_p.h +usr/include/*/qt5/QtQuickControls2/*/QtQuickControls2/private/qquickiconimage_p_p.h +usr/include/*/qt5/QtQuickControls2/*/QtQuickControls2/private/qquickattachedobject_p.h +usr/include/*/qt5/QtQuickControls2/*/QtQuickControls2/private/qquickiconlabel_p.h +usr/include/*/qt5/QtQuickControls2/*/QtQuickControls2/private/qquickpaddedrectangle_p.h +usr/include/*/qt5/QtQuickControls2/*/QtQuickControls2/private/qquickstyleselector_p_p.h +usr/include/*/qt5/QtQuickControls2/*/QtQuickControls2/private/qquickanimatednode_p.h +usr/include/*/qt5/QtQuickControls2/*/QtQuickControls2/private/qquickclippedtext_p.h +usr/include/*/qt5/QtQuickControls2/*/QtQuickControls2/private/qtquickcontrols2global_p.h +usr/include/*/qt5/QtQuickControls2/*/QtQuickControls2/private/qquickcolor_p.h +usr/include/*/qt5/QtQuickControls2/*/QtQuickControls2/private/qquickproxytheme_p.h +usr/include/*/qt5/QtQuickControls2/*/QtQuickControls2/private/qquickitemgroup_p.h +usr/include/*/qt5/QtQuickControls2/*/QtQuickControls2/private/qquickchecklabel_p.h +usr/include/*/qt5/QtQuickControls2/*/QtQuickControls2/private/qquickstyle_p.h +usr/include/*/qt5/QtQuickControls2/*/QtQuickControls2/private/qquickstyleselector_p.h +usr/include/*/qt5/QtQuickControls2/*/QtQuickControls2/private/qquickiconimage_p.h +usr/include/*/qt5/QtQuickControls2/*/QtQuickControls2/private/qquickstyleplugin_p.h usr/include/*/qt5/QtQuickTemplates2/QtQuickTemplates2 usr/include/*/qt5/QtQuickTemplates2/QtQuickTemplates2Depends usr/include/*/qt5/QtQuickTemplates2/QtQuickTemplates2Version usr/include/*/qt5/QtQuickTemplates2/qtquicktemplates2-config.h usr/include/*/qt5/QtQuickTemplates2/qtquicktemplates2version.h +usr/include/*/qt5/QtQuickTemplates2/*/QtQuickTemplates2/private/qquickswipedelegate_p_p.h +usr/include/*/qt5/QtQuickTemplates2/*/QtQuickTemplates2/private/qquickaction_p_p.h +usr/include/*/qt5/QtQuickTemplates2/*/QtQuickTemplates2/private/qquickoverlay_p.h +usr/include/*/qt5/QtQuickTemplates2/*/QtQuickTemplates2/private/qquicktextfield_p_p.h +usr/include/*/qt5/QtQuickTemplates2/*/QtQuickTemplates2/private/qquickdelaybutton_p.h +usr/include/*/qt5/QtQuickTemplates2/*/QtQuickTemplates2/private/qquickroundbutton_p.h +usr/include/*/qt5/QtQuickTemplates2/*/QtQuickTemplates2/private/qquickswitchdelegate_p.h +usr/include/*/qt5/QtQuickTemplates2/*/QtQuickTemplates2/private/qquickpane_p_p.h +usr/include/*/qt5/QtQuickTemplates2/*/QtQuickTemplates2/private/qquickrangeslider_p.h +usr/include/*/qt5/QtQuickTemplates2/*/QtQuic
Bug#958521: qtquickcontrols2-5-dev: Private headers missing
Hi Olaf! On Thu, 23 Apr 2020 at 07:27, Olaf Mandel wrote: > > Package: qtquickcontrols2-5-dev > Version: 5.11.3+dfsg-2 > Severity: important > Tags: patch > > Dear Maintainer, > > the private headers and modules are missing from this development > package for both modules quickcontrols2 and quicktemplates2. These files > are important if the user wants to compile a project that contains > either of these module dependencies: > > QT += quickcontrols2-private quicktemplates2-private > > Currently, such a compile fails as the *.pri files (not to mention the > header files) are missing. > > Note that while compiling against Qt private modules may not be good > form, it is allowed and I would expect this to be possible with > Debian-provided Qt modules (it is with the qtbase ones). We do indeed remove all private headers except for the ones required by another submodules (that's why qtbase ships them). > One can argue about creating an extra package just for the private > development files, but in the attached patch I opted to include the > files together with the public ones. That's a very bad idea, private headers are not API/ABI stable. *Maybe* we can add the private headers for everything in the last Qt 5 upload, as it will switch to Qt 6 after all. But that's to be decided. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/
Bug#958521: qtquickcontrols2-5-dev: Private headers missing
Dear Lisandro, Am 23.04.2020 um 14:19 schrieb Lisandro Damián Nicanor Pérez Meyer: > On Thu, 23 Apr 2020 at 07:27, Olaf Mandel wrote: >> QT += quickcontrols2-private quicktemplates2-private >> >> Currently, such a compile fails as the *.pri files (not to mention the >> header files) are missing. >> >> Note that while compiling against Qt private modules may not be good >> form, it is allowed and I would expect this to be possible with >> Debian-provided Qt modules (it is with the qtbase ones). > > We do indeed remove all private headers except for the ones required > by another submodules (that's why qtbase ships them). > [...]> That's a very bad idea, private headers are not API/ABI stable. > Couldn't this uncharitably be reinterpreted as "we remove these headers for others use as undesired because they are not API/ABI stable... except for cases where we ourselves need them"? What is the difference between Debian-maintained packages and user-compiled software that justifies making compiling the latter more difficult than the former? In Debian-packages, the Build-Depends/Depends fields can be set to the exact version of the dependent library to ensure API/ABI compatibility. Why couldn't the user do something similar? Or if/when they don't recompile after an upgrade, then this is the users lookout (IMO). > *Maybe* we can add the private headers for everything in the last Qt 5 > upload, as it will switch to Qt 6 after all. But that's to be decided. > I am not sure that this would match my expectations: Once Qt6 comes out, I would probably rewrite my code to compile under Qt6 and if I still needed the private parts, I would have this same problem again until Qt7 comes out... Given both of these points, I at least would prefer to have the private headers available, even to non-package developers. The one thing I could understand is that the private headers are in a new package qtquickcontrols2-5-private-dev instead of in the "normal" qtquickcontrols2-5-dev. That might serve as an extra level of warning to the user. Best regards, Olaf Mandel signature.asc Description: OpenPGP digital signature
Bug#958521: qtquickcontrols2-5-dev: Private headers missing
Hi Olaf! On Thu, 23 Apr 2020 at 12:02, Olaf Mandel wrote: > > Dear Lisandro, > > Am 23.04.2020 um 14:19 schrieb Lisandro Damián Nicanor Pérez Meyer: > > On Thu, 23 Apr 2020 at 07:27, Olaf Mandel wrote: > >> QT += quickcontrols2-private quicktemplates2-private > >> > >> Currently, such a compile fails as the *.pri files (not to mention the > >> header files) are missing. > >> > >> Note that while compiling against Qt private modules may not be good > >> form, it is allowed and I would expect this to be possible with > >> Debian-provided Qt modules (it is with the qtbase ones). > > > > We do indeed remove all private headers except for the ones required > > by another submodules (that's why qtbase ships them). > > [...]> That's a very bad idea, private headers are not API/ABI stable. > > > Couldn't this uncharitably be reinterpreted as "we remove these headers > for others use as undesired because they are not API/ABI stable... > except for cases where we ourselves need them"? Exactly that, yes. > What is the difference between Debian-maintained packages and > user-compiled software that justifies making compiling the latter more > difficult than the former? In Debian-packages, the Build-Depends/Depends > fields can be set to the exact version of the dependent library to > ensure API/ABI compatibility. Why couldn't the user do something > similar? Or if/when they don't recompile after an upgrade, then this is > the users lookout (IMO). Because in our use case (qt submodules) we know beforehand that the API/ABi will work, because it's a matter of splitting Qt into submodules (we could build Qt from one huge tarball, but that would be insane). We are currently forced to do transitions on **every** Qt upload, and the amount of work third party apps using private headers gives us is defintely more than enough. So yes, the less private headers, the better. > > > *Maybe* we can add the private headers for everything in the last Qt 5 > > upload, as it will switch to Qt 6 after all. But that's to be decided. > > > I am not sure that this would match my expectations: Once Qt6 comes out, > I would probably rewrite my code to compile under Qt6 and if I still > needed the private parts, I would have this same problem again until Qt7 > comes out... Exactly. Don't use private headers. If you need them work with Qt upstreams to make them public API. > Given both of these points, I at least would prefer to have the private > headers available, even to non-package developers. The one thing I could > understand is that the private headers are in a new package > qtquickcontrols2-5-private-dev instead of in the "normal" > qtquickcontrols2-5-dev. That might serve as an extra level of warning to > the user. People would still use them in their packages, so no. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/
ktp-accounts-kcm is marked for autoremoval from testing
ktp-accounts-kcm 17.08.3-2 is marked for autoremoval from testing on 2020-05-14 It (build-)depends on packages with these RC bugs: 952060: libsignon-glib: FTBFS: signon-auth-service.c:72:13: error: G_ADD_PRIVATE [-Werror]
