RFC: Deprecate support for Linux SNAP packaging

Summary:

This is an RFC proposal to remove support for SNAP packaging for O3DE due to numerous issues with how O3DE is packaged with SNAP and its low adoption rate.

What is the motivation for this suggestion?

SNAP packaging provides discoverable, cross-platform, dependency-free installations of applications. It is a popular method of distribution of major applications on any Linux distribution/host that supports SNAP. Initially, this seemed like a good fit to use for O3DE as a path for installation since O3DE has a lot of dependencies and can be a challenge to install.

However, as the SNAP package was developed, a lot of work-arounds were done to end up with a hybrid snap package that no longer provided the portability and dependency-free environment that SNAP is known for. There are many reasons for this:

The O3DE libraries still require several packages to be installed as a per-requisite, even though SNAP is suppose to be dependency free. These packages are clang, stdlibc++, cmake, ninja. This cancels out the dependency-free advantage of SNAP packaging. These packages can be included in the confinement, however, but would add more package dependency bloat and would prevent users to use anything but the build tools specified in the package.
O3DE relies on O3DE-specific runtime 3rd party packages that are downloaded on demand and is done outside of the snap confinement. These additional packages already restrict the portability of the installation to machines whose minimum version of glibc must be 2.27 or greater.
If these packages were included in the snap package, this would bloat the package by about 5 GB.
O3DE relies on an O3DE-specific private build of Python which is downloaded on demand as part of the bootstrap process. Although python itself is downloaded outside of the confinement, when a python virtual environment is generated for O3DE, it attempts to register python libraries internal to the engine using the egg-info creation process, which requires writing to the source script. This is not possible in a read-only confinement, so a work-around for this was to do the bootstrap before creating the snap confinement, creating the egg-info files, and then when the SNAP package is installed, the virtual environment creation will not need to create the egg-info files in the containment.
The game projects that are built from a snap installed O3DE will require the O3DE snap package to be installed in order to run on other machines (unless the game is exported to a game package).

Although all of the above issues may be fixable, it may require significant work and possible work-arounds just to make O3DE running without external dependencies in an isolated environment and address the issues caused by its immutable confinement.

Considering that there is already support for a debian package as an alternative installation path, there is no critical need to keep supporting SNAP packaging.

Suggestion design description:

The following steps need to be done to remove SNAP support

Remove the SNAP packaging scripts and work-arounds in the engine code
Remove the SNAP packaging build configuration
Remove O3DE from the official SNAP store
Remove SNAP references in o3de.org and the official documentation

What are the advantages of the suggestion?

This will simplify the linux installation packaging workflow a bit by removing SNAP and just maintaining the debian packaging process

What are the disadvantages of the suggestion?

The advantage that SNAP currently has and is used by O3DE is the SNAP store. No separate downloads and installation is necessary, since the SNAP store is already configured on many Linux distributions. (The prequisite requirements are still necessary, however)
Removing the snap option will only leave downloading from o3debinaries.org

Are there any alternatives to this suggestion?

Although removing from the SNAP store will make it less convenient to discover and download the O3DE installation, there are a few alternatives that can be explored

Hosting the debian package in a custom repo and provide its path using debian source lists
Requesting the debian package be registered in the ubuntu distro list.

What is the strategy for adoption?

Users will need to install O3DE on linux using the debian package at o3debinaries.org

o3de / rfcs