Hefee:
Package: debhelper Version: 13.31 Severity: normal X-Debbugs-Cc: [email protected] Control: block 1072698 by -1Hey, I write here as author of dh_qmldeps a tool to detect QML depdendecies in files.
Hi, Thanks for reaching out.
The tool only returns a list of dependencies that are placed into qml6:Depends - as the tool cannot know if the qml file is needed or not.
I have read a bit of the `dh_qmldeps` code and I would not say I have a full understanding yet.
Nevertheless, I believe it is a correct statement to say that:
1. A binary package can contain 0 or more qml files and `dh_qmldeps`
would read all of them.
(ukui-panel has 6 of them as an example)
2. Each `.qml` file can cause `dh_qmldeps` to add 0 or more
dependencies as a consequence of that `.qml` file. I presume it is
the `import` or `depends` statements in them that does it
(via `detect_qml_deps_in_qmldir`)
In other words:
1 pkg -> N qmlfile
1 qmlfile -> M dependencies
I hope you would agree with the above assessment and I will be writing
the rest of my answer on the assumption that it is correct. If my
assumption is incorrect, my answer will likely be as well as a consequence.
[...] Still I'm not sure how to fix dh_qmldeps or how to do demotion for specific packages.
I would start by rephrasing the problem. The emails you link to is about how maintainers/packages would handle special cases. I think you as tool writer should rather approach this problem from the angle of adding conventions to `dh_qmldeps` to make it smarter at picking the right dependency strength.
Part of answering this is figure out what kind of interface will you promise your users. I can give you some ideas, but at the end of the day, it ends up being between the users and the maintainers of `dh_qmldeps` to negotiate the contract.
Notably, I suspect `dh_qmldeps` has a very strong tie to the KDE team, which means you have a very well-defined user group and an easy way to reach them for having the discussions on what is the desired behaviour (what should `dh_qmldeps` do by default vs. what should require a manual override).
Nonetheless, I would expect `dh_qmldeps` would want additional "smarts" about some of these cases to split the result better by default.
I have several examples where a qml dependecy needs to be demoted in the Qt/KDE maintainer umbrella. (full demotion): kquickimageeditor-dev: only the examples have qml files. That's why recommending all the qml depdendecy seems resonable. The normal usecase of an dev package is to be used to build other packages. Installing the dependencies for examples is too much.
I see a pattern of `.../examples/.../*.qml` here (some in `/usr/share/doc`, others in `/usr/lib/${MA_DIR}/qt5/examples`).
For me, this looks like a promising start for a split. For QML files matching those patterns, they are not hard `Depends` and would go in either `Recommends` or `Suggests` by default (I do not know what the convention is on dependency strength for examples in the `qml` world).
It would require some code work surely for `dh_qmldeps` to split the `qml` files into two buckets, but it would mean that these would work a lot better out of the box for these packages.
(The tool does not have to worry about common dependencies that end up in both the weaker and the stronger case from a duplication PoV, as dpkg will clean that up)
(partial demotion): libkf6purpose-bin: A tool to provide functionality allover the plasma desktop to share files and other things. As it support a bunch of different targets. You may want to not install every dependency as you do not want to install kdeconnect so do not depend on qml6-module-org-kde-kdeconnect. And at that time where the recommend was added, qml6-module-org-kde-kdeconnect does not existed yet in unstable. qml6-module-org-kde-purpose is needed to be demoted as otherwise we would face a circular dependency.
Here we come back to the interface question. The `dh_qmldeps` could grow a CLI like `dpkg-shlibdeps` where you can decide which file goes into what dependency.
Or you can start simpler and ask maintainers to rely on `--exclude` to skip the files and then manually maintain those dependencies. Or you can even continue to with the "fixup" thing you are doing already where explicitly mentioned dependencies overrule the substvar.
I have my personal opinions on the matter, but frankly what matters is that it makes sense for `dh_qmldeps` and for its users. Since they are already used to this "If I list explicitly in Recommends, then that is where I get it", then perhaps it is completely fine for now to continue that approach.
I know, partion demotion doesn't work within Dh 13 too. So I created a workaround to implement it: After generation the dependency list, go through the Depends/Recommends/... fields in d/control and removes all the explicit mentioned dpendendencies of those fields. https://salsa.debian.org/qt-kde-team/pkg-kde-tools/-/blob/master/pythonlib/qmldeps.py?ref_type=heads#L396 That works and would work in Dh 14 too - but as far as I understand it is against the idea behind the automatic use of the substvars fields, that does not support demotion.
I would not say it is against the idea of automatic substvars fields. What my proposal is about is to make us stop having to write and maintain boilerplate like some infinite combination of:
Depends: ${misc:Depends}, ${shlibs:Depends}, ${sodeps:Depends},
${python3:Depends}, ${some-other-namespace-I-forgot:Depends}
I think if `dh_qmldeps` got an understanding of the "example" `qml` vs.
"real" `qml` files, so it could split them into Suggests/Recommends vs.
Depends, then `dh_qmldeps` is already a lot closer to my ideal than it
was yesterday.
That does not mean there cannot be any special-cases at all and `dh_qmldeps` already has some support for it with its dependency pruning logic.
At least from the documentation it sounds like the tool (dh_qmldeps) needs to support manipulating the vars.
Ideally, due to the "example" case, I would recommend that `dh_qmldeps` learn to generate two buckets of `.qml` files instead of one bucket. That way the dependencies in each bucket will end up being coherent and it would not involve "post-processing" of the substvar. Instead, it might involve running the generation flow twice (once for each case).
I think it would be great, if there is a way to demote in Dh 14 without the tools to support manipulating. Because if no tool exists than a sed/awk needs to be used and this is error-prune. [...] Regards, hefee [...]
I think this is fundamentally the wrong approach for any tool such as `dh_qmldeps` in this area to do. What you describe here is a closer to a maintainer facing tool and not a tool for a substvar-generating `dh_foo`-like command.
Even if `debhelper` was to provide such a tool, would the users of `dh_qmldeps` in your view be best served by having to add manual overrides for common use-cases like the "examples"? I cannot think of a case where I would answer "yes" to it in your position as it conflicts with my vision of "less boilerplate". With that said, I am an outsider to the `.qml`-files, so there can be subtle nuances to this problem that I cannot see. So if you think the answer is "yes", then likely I am missing a key part of the equation to give you a proper recommendation.
Nevertheless, I hope that was useful as a recommendation or, failing that, at least a conversation starter for how to improve `dh_qmldeps`.
Best regards, Niels
OpenPGP_signature.asc
Description: OpenPGP digital signature
