Traditional (apt/rpm) software packages

[MOZGIII]

For the use case of installing this one the existing workstation (in contrast to installing it on a dedicated server) it would be great to provide Flatpack (and/or Snapcraft) and deb/rpm packages.

Using it on the workstation has the benefits of cutting the time to setup all the tooling on the server and jump string into what you want to do.

[sr229]

@MOZGIII I think @nhooyr wouldn't like supporting every use case, plus I made a Ansible script if you're just aiming for such. It supports install lifecycle and can be used as update as well.

[MOZGIII]

Well, personally I'm ok with using just a binary. Ansible scripts is something that I'd keed away from the workstation.
I guess I'll just set up a ppa for ubuntu myself as a first step. After that it'd be easy for the upstream to pick up.

Also, on the second thought Flatpak is not really a good idea, because it would make the tools and other processes spawned by the editor exectue in the context of the container, which kind of makes no sense to do if the goal is to use stuff from the plain-old host environemnt. I'm renaming this issue to just deb/rpm.

[sr229]

Also using Flatpak is a big security hole. Isolation is pretty much breakable compared to Snap (which I personally discourage for security sensitive workloads)

[MOZGIII]

Snap, Flatpak, Docker and any container-based "isolation" is too easy to subvert, so it can't really be used as a security measure. gVisior is the closest candidate to have something securely isolated, but there may be ways around it too.
However, my point is that to not explicitly use host-native environment without containment of the code-server space.
I'm currently going through the build system - there's quite a lot of things going on, and I seem to have issues with figuring it out. In particular, it looks like it's not supposed to work without packing into a single binary, which is surprising.

[nhooyr]

We should build a .deb as part of the build process.

[nhooyr]

See #1306