Add deb and rpm distribution to CI

[hello-adam]

It would be nice to have hobbits packaged in a way that let plugin developers update the application/headers/library easily using a package manager. We could provide the following packages:

• hobbits-devel (requires everything?)
• hobbits (requires everything except libhobbits-devel and hobbits-qt-creator-wizards)
• hobbits-gui (gui binary, requires libs and plugins)
• hobbits-runner (CLI runner binary, requires libs and plugins)
• hobits-core-plugins (core plugin binaries, requires libs)
• hobbits-qt-creator-wizards (wizard templates for Qt creator)
• libhobbits-devel (includes headers for plugin development, requires libs)
• libhobbits (binary libraries, requires Qt 5.12+)

A few non-trivial things that might need to be addressed:

• where do we host these?
• which parts of hobbits-core are "public"? everything right now?
• how do we make the packages? (seems like CMake can help, see #13 )

@KOLANICH

[KOLANICH]

Moved from https://github.com/Mahlet-Inc/hobbits/issues/13#issuecomment-598418790

Do you have any recommendations for how/where to host packages for the various platforms?

Not quite. I currently use GitLab CI on gitlab.com for building some packages (pipeline creates a repo, and that repo is available via GitLab Pages because GL pipelines can create GL pages). But I am dissatisfied with 2 things: 1 GitLab is doing bad things and continues doing them. It may make sense to stay away of GitLab. 2 CIs run Turing-complete code, and it cannot be sandboxed reliably. GL CI runs code from anyone. GL uses hw virt to harden the security, but there were multiple vulnrs in various hw virt solutions allowing to compromise the host. Once host is compromised, one can compromise all the VMs and infect all the software built in them with malware. One of the means to reduce probability of this scenario is to build on machines not shared with anyone in the world wishing it. It is not a panacea though: on the same machines other software is built and run, and when done without proper care the code run may be infected. So the ideal variant is a dedicated physical machine.

So, the best variant is to bring it to the official repos and trigger the builds using HTTP hooks. It may make sense to make the pipelines to check the signatures on commits.

[KOLANICH]

We could provide the following packages

CMake + CPack introduced in #16 does something like this (and even a bit more, each module goes into an own package). Also please note that usual naming convention (at least in Debian-based distros) is that packages with libs have lib in their names (usually as a prefix, so libhobbits and libhobbits-dev).

hobbits-devel (everything) I guess doesn't match the way distros use to separate software into packages.

Also we need separate packages for wizards.

[hello-adam]

looks like packages can be hosted on BinTray with a free open source plan: https://bintray.com/

[KOLANICH]

Yes, it can, KS for example hosts nightly packages there. But IMHO

• doing everything on distros infrastructure is more secure;
• count of intermediares should be reduced, not increased. More intermediares and accounts - higher risk one of them can be compromised.

[hello-adam]

I'm sort of tempted to just publish 2 packages - hobbits and hobbits-dev(el). Sure, there are multiple binaries, and maybe even use-cases for the core library by itself, but I don't think the potential disk space savings outweigh the maintenance/documentation/troubleshooting headache caused by complicated installation permutations.