Do not split QML packages

[Fabian Vogt]

Hi,

Am Samstag, 12. August 2023, 21:11:22 CEST schrieb Lisandro Damian Nicanor Perez Meyer:
> Hi Carl!
> 
> On viernes, 11 de agosto de 2023 11:38:53 -03 Carl Schwan wrote:
> > Hello,
> > 
> > I just receive yet another bug report about a QML module not being installed
> > by an user using a Debian based distributions (KDE Neon Unstable). This is
> > caused by the fact that Kirigami Addons 0.9 added a new module
> > (org.kde.kirigamiaddons.delegates) and Merkuro and a bunch of other apps in
> > KDE Gear 23.08 require this module.
> > 
> > Merkuro correctly bumped the dependency in its cmakelists.txt file to depend
> > on Kirigami Addons 0.9 which should have ensured that the module is
> > installed.
> > 
> > But since some distributions are splitting the kirigami addons in many micro
> > packages and forgot to add the new module in their dependency list for
> > Merkuro (and probably other apps), the new required module isn't installed
> > and the app crash on startup. This is not the first time this happen.
>
> I am not the one who split kirigami *but* I am the one that defined [this 
> policy] long ago.
> 
> [this policy] <https://qt-kde-team.pages.debian.net/qmlmodulesnaming.html>
> 
> Back at the time this was defined, and as I can remember, QML modules where 
> designed as libraries, where a developer is free to use whatever it needs from 
> them and only those really required at runtime are really needed. So splitting 
> has (and still has) a lot of sense, specially if some module adds a 3rd 
> dependency you never need, or even more, you would not like on your system.
>
> That being said:
>  
> > Please do not split Kirigami Addons in many small packages. Kirigami Addons
> > is meant to be packaged as one single package and some QML modules even
> > depends on each others. The different QML imports are only for the
> > developer convenience and should be considered like C++ namespace as
> > something only interesting in the code.
> 
> This is totally fair to ask **but** be verbose on README (in case you haven't, 
> again, I'm not kirigami's packager). I can totally understand you consider 
> them "a single thing under a namespace", but that's not what the original 
> design was meant to. Again, totally fair, but only if you express this as 
> such.
> 
> > Kirigami itself will also be spitted in multiple QML modules in KF6 and
> > similarly this should result in one package and not multiple one.
> 
> Perfect. Again, if not there, please add a note on toyur README.
>
> > Sorry for being a bit angry, but I received a lot of reports about this
> > across years in bugs.kde.org, on Matrix, on Mastodon and even on blog
> > posts. This gives the user a very bad impression as the application crash
> > on startup and I find myself in a frustration situation because the
> > packaging of my apps is outside my reach and I can't fix it myself.
> 
> While I can understand this please take into account that, by design, QML 
> modules should be independent unless they have an explicit interdependency on 
> them. And even in that case, to the best of my knowledge, they are not easy to 
> catch so errors might happen.

IMO the split itself isn't technically wrong and not fully the root cause.
It's mostly that dependencies are handled in a manual manner, which is always
error prone.

This can be improved by scanning the installed files for dependencies, like
it's already done for shared libraries.

In openSUSE we do that for .qml files already
(https://build.opensuse.org/package/view_file/openSUSE:Factory/qml-autoreqprov/README?expand=1),
but most applications and some libraries ship QML code as Qt resources, which
aren't accessible from the outside. Ideas welcome.

QML modules also define dependencies in the qmldir file, which can be utilized.

Cheers,
Fabian

> Kinds regards, Lisandro.