CQtDeployer - It is utiliry for deploy cpp, Qt and QML applications.
Since the utility is deploying applications using some options, it needs to copy system libraries to distribute the custom application. I did not find any other solutions except for the classic mode. Prior to this, the utility worked exclusively in user space, but I constantly received complaints from users that not all the functionality of this utility works. This was primarily related to restricting access of the snap package.
How to work CQtDeployer
СQtDeployer will scan the target application then get a list of dependencies and copy all dependencies to the distribution.
Source code and snapcraft.yaml of CQDeployer see on branch task-368 because it is in this branch that snapcraft was rewritten to work in classic mode.
Version of CQtDeployer on snap-store with changes of task-368 in build #145 22.214.171.124
The discussion on solving access problems was conducted here
From what I can tell this application wraps qmake to both compile and then package Qt applications for distribution - @EndrII would this be a reasonable summary of
Since this is compiling the application, could the
CQtDeployer snap also ship
qmake and the various libraries to distribute the custom application itself and so avoid having to access these from the host system?
CQtDeployer does not currently compile the application, it only packages the already compiled application. But in the future, I do not exclude the addition of such functionality.
Unfortunately, I cannot predict which libraries the user may need for deployment. Perhaps he installed something from third-party repositories or compiled something on his own and this library is located in “/usr/lib”. So I won’t be able to install the full set of required packages into the snap-in.
There is 1 question, I am currently using ‘confinement: classic’ and ‘plugs: [classic-support]’ at the same time.
What is the difference between them and can I get by with just ‘confinement: classic’ or ‘plugs: [classic-support]’ ?
classic-support interface is deprecated, and was meant for the specific
classic snap on Ubuntu Core. You should use
confinement: classic for now.
CQtDeployer must have access to the host filesystem in order to obtain the files, but it sounds like it only needs read access to the hostfs. Considering that an interface like
system-backup gives read-only access to the host filesystem via /var/lib/snapd/hostfs, would it be possible for CQtDeployer to look for files there? If so, it could be made strict (and therefore enjoy all the benefits of a stable runtime environment which classic snaps have to take great care to run reliably cross-distro).
If not, I would say this fits broadly into the supported ‘IDE’ category since it needs access to things in the host filesystem to construct the application (not to mention, actual compilation is a future feature of CQtDeployer) and these actions are driven by the user, without need for root-running daemons.
system-backup - should solve my problem. But the difficulty lies in the fact that the file system will be located in a separately mounted location. This requires additional tests of the snap version separately from the base version of the program, I think it will cause new problems.
So specifically in the case of cqtdeployer, it’s better to use classic mode.
Many applications perform runtime checks and alter their behavior accordingly. One method people use it to check if the SNAP variable is in the environment; you could use this to conditionally prepend /var/lib/snapd/hostfs to the files which could in theory be abstracted to a single helper function which wouldn’t require separate code bases and shouldn’t introduce problems.
I’m still of the opinion that this fits broadly into the supported ‘IDE’ category and open to granting classic, but considering the above and that great care must be taken for classic snaps to work reliably across all distributions (see ‘Caveats’ from Process for reviewing classic confinement snaps), are you sure your application can’t be made to work well in strict mode?
I am also a supporter of strict pockets.
Let’s do it like this:
I will try to implement all functionality in strict mode in the near future.
I will definitely write about the results here.
If I come across unsolvable problems, then we will use the classic mode.
I managed to dig 90% of all functionality using system-backup.
so at this stage the classic mode is not required yet. Thank you all for your help. If I have a need to implement the functionality of building applications by forces, cqtdeployer I will open a new request for the classic mode for cqtdepoyer.
Thanks - I will remove this request from our queue then.