QML Dependency tracking in Debian
Tracking library dependencies work in Debian to resolve from symbols usage to a library and add this to the list of dependencies. That is working for years now. The KDE community nowadays create more and more QML based applications. Unfortunately QML is a interpreted language, this means missing QML dependencies will only be an issue at runtime.
To fix this I created dh_qmldeps
, that searches for QML dependencies at build time and will fail if it can't resolve the QML dependency.
Me didn't create an own QML interpreter, just using qmlimportscanner
behind the scenes and process the output further to resolve the QML modules to Debian packages.
The workflow is like follows:
The package compiles normally and split to the binary packages.
Than dh_qmldeps scans through the package content to find QML content ( .qml
files, or qmldir
for QML modules).
All founded files will be scanned by qmlimportscanner
, the output is a list of depended QML modules.
As QML modules have a standardized file path, we can ask the Debian system, which packages ship this file path.
We end up with a list of Debian packages in the variable ${qml6:Depends}
.
This variable can be attached to the list of dependencies of the scanned package.
A maintainer can also lower some dependencies to Recommends or Suggest, if needed.
You can find the source code on salsa and usage documentation you can find on https://qt-kde-team.pages.debian.net/dh_qmldeps.html.
The last weeks I now enabled dh_qmldeps
for newly every package, that creates a QML6 module package.
So the first bugs are solved and it should be usable for more packages.
By scanning with qmlimportscanner
trough all code, I found several non-existing QML modules:
import QtQuick3DPrivate
qt6-multimedia - no Private QML module QTBUG-131753.import QtQuickPrivate
qt6-graphs - no Private QML module QTBUG-131754.import QtQuickTimeline
qt6-quicktimeline - the correct QML name isQtQuick.Timeline
QTBUG-131755.import QtQuickControls2
qt6-webengine - looks like a porting bug as the QML6 modules name isQtQuick.Controls
QTBUG-131756.import QtGraphicalEffects
kquickimageeditor - the correct name is for QML6 isqt5compat.graphicaleffects
, properly as it is an example nobody checks it kquickimageeditor!7.
YEAH - the first milestone is reached. We are able to simply handle QML modules.
But QML applications there is still room for improvement. In apps the QML files are inside the executable. Additionally applications create internal QML modules, that are shipped directly in the same executable. I still search for a good way to analyse an executable to get a list of internal QML modules and a list of included QML files. Any ideas are welcomed :)
As workaround dh_qmldeps
scans currently all QML files inside the application source code.