Bug#950926: ember: Using packages to install "snap" packages is not a correct use of the packaging system

[Simon McVittie]

On Tue, 25 Feb 2020 at 15:02:21 +0000, Jonathan Dowland wrote:
> It would be interesting to see whether game-data-packager could consume
> data from snaps, and avoid all these pitfalls.

That would remove the sandboxing and known-runtime-libraries properties
of the snap packaging system. I wouldn't recommend that. The apt/dpkg
packaging system is set up for a single, system-wide dependency
tree. That's great for binaries that were built within the scope of
that dependency tree, but unsuitable for binaries that were built with
different assumptions (unless the binaries were deliberately built to
have minimal dependencies, like the few proprietary binary-only games
supported by game-data-packager, or with no assumptions at all, like the
data for Free game engines that is the majority of what game-data-packager
deals with).

If what you want is to install Snap packages, then I would suggest
installing Snap packages (perhaps through something like GNOME Software,
which knows about multiple ways to install software). Not every piece
of software has to be delivered as a .deb.

If ember is no longer feasible to package as a .deb in Debian, then only
releasing new versions of it as Snap packages (or Flatpak or AppImage
or whatever) is perfectly reasonable; but in that case, I don't think
a .deb package that installs those other-packaging-system packages from
third-party repositories is a great upgrade path.

> I believe smcv was
> interested in something similar for flatpaks (that might have been
> installing into flatpaks, rather than consuming from them)

Off-topic for Ember:

Yes, this is the other way round. I wanted to be able to turn games
(particularly proprietary games like Unreal 1) into Flatpak packages as
an alternative to .deb (and .rpm and Arch Linux packages, which should
now mostly work too). Some of the same reasoning would apply equally to
turning those games into Snap packages, although I think Flatpak is a
better fit, so I don't plan to work on that myself.

Why I wanted to do that:

- Flatpak apps are, or can be configured to be, sandboxed (placed in a
  limited container without access to, for example, ~/.ssh). Snap has the
  same idea, although the details are different (Flatpak is likely to be
  a lot better-confined on systems that don't have Ubuntu's non-upstream
  kernel patches for better AppArmor).

- Flatpak apps run on a set of libraries that don't have to match the ones
  on the host system, so we can run proprietary games from the distant past
  in (for example) a Debian-10-based container that has SDL 1, GTK 2, etc.
  without having to keep those libraries in the development branch of Debian
  forever. I think Snap can do the same thing, but the details of how it
  achieves it are rather different.

- Flatpak apps can be installed "for just me" (in ~/.local/share)
  unprivileged, or system-wide (into /var/lib) with appropriate privileges.
  I don't think Snap apps can be installed per-user without exercising
  privileges.

- Identical files in Flatpak apps are automatically deduplicated by
  content (this is relevant if you have overlapping games installed,
  like Unreal, Unreal Gold and Unreal Tournament). I don't think Snap
  does this.

    smcv