[CMake and run time dependencies] Re: Do not split QML packages

[Lisandro Damián Nicanor Pérez Meyer]

El martes, 15 de agosto de 2023 10:26:02 -03 Carl Schwan escribió:
> On Tue, Aug 15, 2023, at 2:16 PM, Sandro Knauß wrote:
> > Hey,
> > 
> > > The policy may have seemed a good idea back then when it was introduced, 
but
> > > in my opinion the right thing to do [after it has been the cause of so 
many
> > > issues that could have been avoided] would be to reconsider it and 
ideally
> > > reach the conclusion of not splitting up QML packages into a multitude 
of
> > > small-QML packages.
> > 
> > The base problem, is that there is no proper way to detect QML 
dependencies.  
> > All distribution needs to manage them manually or have some of basic 
scripting 
> > to detect those dependencies. Keep in mind that build depdendecies != 
binary 
> > dependencies.
> 
> While technically not correct, marking the qml modules as build dependencies 
has
> been very helpful for preventing this sort of issues, by creating explicit 
compile
> failures when a new qml dependency is added. Since I started adding these 
for
> Kirigami Addons and other QML libraries, I didn't get any report coming from 
Fedora
> users (which was previously also a source of frustration).
> 
> > 
> > It won't help at all to have only one qml package per repo.
> > 
> > I install kirigami-addons-dev (that will install all the qml packages) as 
> > build dependency, this doesn't automatically make the binary depend on any 
qml 
> > package. So this list must managed by hand (independently if all qml is 
> > shipped in one or multiple packages). Okay it is easier to just add one 
> > package, but in the end it is error prune to do this all by hand. And a 
> > standardized automatic way would help a lot.
> 
> If this can help, it wouldn't be difficult to maintain a list of import names 
for each app
> and store it as a file in the repository and ensure with a CI script that the 
list is keep
> up to date. E.g. something generated with your grep script or something 
similar. I have:
> 
> grep -hre '^import org.kde' -e '^import Qt' src | sed 's/import //' | sed 
's/as .*$//' | sed 's/ [[:digit:]]*\.[[:digit:]]*//' | sort | uniq
> 
> We could even use qmldom for this but that might bit over-engineered. But in 
any case,
> it would put the responsibility of keeping the list of dependencies up to 
date on the
> app developers and then we can blame ourselves and not distros when 
something is
> missing ;)

Errors happen at any level, it's not a matter of "blaming", if we find a way in 
which all of us can be more or less happy with it then the better. To be 
honest this is for me a specification error/omission at QML-level, and maybe 
"upstream" here should be Qt itself. Note I am not blaming them, I am just 
saying we might want to create a solution that can be pushed to Qt itself.

This issue does not only appears on distributions, it is also an issue that 
happens at other levels too even in non-Debian environments. I see it 
frequently at $JOB. Sometimes shipping "everything just in case" is simply not 
the easiest solution.

Now, speaking with a "dev" hat on, I should really find the time to see what 
others did and check what can be done. It's easier to speak^w write an email 
rather than writing code :-D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/distributions/attachments/20230815/24010e26/attachment.sig>