Make it possible for pure-QML apps to use `-qml` variant of framework (and perhaps use by default)

The original concept of Click frameworks is that they are "contracts" between the platform (OS) and apps [1], which can be as broad or as narrow as we like. However, because we've never concretely defined this contract, currently the ubuntu-sdk-20.04's de-facto contract has been "everything on the 20.04 images".

This becomes a problem on Noble-based images; compared to Focal, it contains libssl.so.1 -> libssl.so.3 transition. This mean the top-level ubuntu-sdk-20.04's contract can no longer be maintained and the framework will (in principle) have to be removed. Applications using ubuntu-sdk-20.04 framework will have to be re-built in order to be able to run on Noble-based images again, which could be a churn on some developers.

However, there is the smaller variant of the framework, ubuntu-sdk-20.04-qml, which could be understood as "pre-installed QML types". Since Noble-based images will not have QML API changes, they will be able to retain ubuntu-sdk-20.04-qml framework on the images, and apps using ubuntu-sdk-20.04-qml framework will be able to run on them.

Currently, every app built using e.g. 20.04 images gets CLICK_FRAMEWORK value of ubuntu-sdk-20.04 i.e. the full variant. However, for QML apps, merely using ubuntu-sdk-20.04-qml should be enough. If enough apps use -qml variant, it'll allow Noble-based Ubuntu Touch images to remove ubuntu-sdk-20.04 and retain ubuntu-sdk-20.04-qml, knowing that at least pure QML applications will be able to run without re-compiling.

In the future, it's probably worth it to define more concretely which library/QML type is part of the "contract". For example, we could define that e.g. libssl.so.3 is not part of the framework's contract while libQt5Quick.so.5 is, allowing most native applications to stay compatible with future versions. For apps that need to link to libssl.so.3, an -internal variant could be provided that will be removed every time a new major version is released.

[1]: https://wiki.ubuntu.com/Click/Frameworks#Overview

added discussion packaging labels

The most obvious change would be to fine tune the framework field for the app templates instead of leaving it for Clickable to fill during packaging. The current approach was meant to ensure consistency between target and build environment, but falls short of the necessary distinction mentioned above.

mentioned in merge request !653 (closed)

I was thinking about this a bit. Since we already know if the app is a qml-only app by the builder type, we can automatically append the -qml to the framework in those scenarios. @jonnius let me know what you think of this MR: !653 (closed)

Sounds like a good idea to me.

Could you also review that one, @peat-psuwit, please?

I think, the main question at hand is whether tooling (app template and clickable) are in a position to decide on the framework or the app developer needs to decide anyway. If the latter was true, we shouldn't introduce obscure logic to try the first. Then I'd reduce the program logic to applying plausibility checks and printing warnings. And we might need to force the developer to decide, either on app creation and/or via Clickable. What do you think?

Hmm... the "negative" autodetection should be easy: if there exists any ELF binary, then -qml (only) is not applicable. OTOH, a -qml-only application might use some internal-only QML modules, making -qml (only) not applicable either.

But either way, I believe that the application developer should retain the final decision, either via clickable.yml or manifest.json.

(A Click package can declare dependency against multiple (sub-)frameworks, as long as they share the same version. This allows an application that e.g. use QML and Python to depend on -qml and -py, but not the main framework.)

So it sounds like we don't want to auto-detect the framework, but rather update the template to generate with a most appropriate framework for starting out.