Do not split QML packages

[Lisandro Damian Nicanor Perez Meyer]

On sábado, 12 de agosto de 2023 16:27:27 -03 Fabian Vogt wrote:
> 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-autoreqpr
> ov/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.

I do totally agree with that. We (Debian) should really look into implementing 
it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/distributions/attachments/20230812/f4901871/attachment.sig>