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.
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 CQtDeployer?
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.
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?
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.
