Re: PPAs (Re: [Idea] Debian User Repository? (Not simply mimicing AUR))
On Thu, 11 Apr 2019 at 09:54:47 +0000, Mo Zhou wrote:
> On Thu, Apr 11, 2019 at 09:26:15AM +0100, Simon McVittie wrote:
> > On Thu, 11 Apr 2019 at 07:44:30 +0000, Mo Zhou wrote:
> > It might be interesting to look at game-data-packager, which is another
> > tool that builds and optionally installs .deb files for data that is
> > not suitable for the Debian archive (in most cases not even for non-free),
> > without going via a .dsc or source package.
>
> Any link please? Both apt-file-search and google found nothing.
https://tracker.debian.org/pkg/game-data-packager
It's in contrib.
> > I can't help thinking that a sandboxed app system like Flatpak or Snap
> > would be a better fit than .deb for leaf packages that have had minimal
> > or no review and don't really need to be part of the operating system.
> > For various reasons my preference is Flatpak (obviously, I wouldn't
> > maintain it otherwise) but I'm sure that proponents of Snap would tell
> > you that it should also be a candidate.
>
> I don't have experience with Flatpak/Snap. However sandboxing sounds
> great. Is there any existing work that helps one convert existing .deb
> into flatpack/snap format? I'd be glad to enable DUPR build Flatpack/Snap
> packages in the future, if possible.
If your goal is to turn something that is not in Debian into a Flatpak
app, going via a .deb seems an unnecessarily indirect route. Flatpak
already has the flatpak-builder package, which takes a JSON or YAML
manifest and uses it to build software from source, typically by cloning
from a git URL and compiling it in a special "SDK" container that has all
the necessary development tools. As with dpkg, the "source" can be a set
of binary blobs if that's all you have. The software to be downloaded
can be checked against hashes supplied by the maintainer of the Flatpak
app or runtime.
Flathub, the reference Flatpak repository, works by accepting
flatpak-builder manifests and building them. Flathub is analogous to the
role of Dockerhub in Docker, Github in the Go ecosystem, or Launchpad PPAs
in third-party addons for Ubuntu: Flatpak is a federated/decentralized
system in which anyone can run their own repository, a lot like apt,
but Flathub is the large "hub" repository used by anyone who doesn't
have a reason to host their project elsewhere.
Flatpak also has an "extra data" mechanism which downloads and manipulates
binary blobs directly from upstream on the end-user system without hosting
a copy on the Flatpak equivalent of an apt repository, which can be used
for binary blobs that the maintainer of the Flatpak app or runtime does
not have permission to redistribute. The main use case for this is (the
user-space part of) the proprietary Nvidia driver. Again, the binary
blobs are authenticated against hashes supplied by the maintainer of
the Flatpak app or runtime, so that only known-good versions are used.
I assume Snap has something similar to some or all of these but I don't
use it myself and don't know the details. My understanding is that Snap
is less federated/more centralized than Flatpak, but that might be
outdated information.
The "app" (directly-user-facing part) in a Flatpak package will be mounted
on /app and so is expected to be built with --prefix=/app, so you can't
reuse a compiled binary .deb unless it's for something that happens to be
relocatable already. The runtime (chroot-like library stack to run apps)
is built with --prefix=/usr, so it's usually easy to reuse binary .debs
for that.
https://gitlab.collabora.com/smcv/flatdeb builds Flatpak runtimes from
an apt repository using debos and debootstrap. The resulting runtimes
are a Debian-based alternative to the reference "freedesktop" runtimes
published on Flathub, which are either used directly by apps with lighter
dependencies, or used as the basis for the GNOME and KDE runtimes used by
apps with heavier dependencies. The example runtime recipes provided with
flatdeb are "Base", which is a minimal CLI system, and "Games", which can
run OpenArena (and probably nothing else yet).
flatdeb also supports building Flatpak apps from a binary .deb (assuming
its contents are relocatable) or an unpacked source package, but that part
isn't my focus right now and might have stopped working. The example app
recipes provided with flatdeb are hello, bash-static and mesa-utils (built
by unpacking a binary .deb that happens to be sufficiently relocatable),
and OpenArena (a hybrid approach, with ioquake3 and openarena rebuilt from
source, and the openarena-data family of packages unpacked and relocated).
For more information please see my Debconf 17 presentation, linked from
<http://smcv.pseudorandom.co.uk/2017/flatpak_and_debian/>.
At the moment my focus in my work project is using flatdeb-built
runtimes for ad-hoc containers that share bubblewrap, Flatpak's
container-runner/sandbox helper, but do not actually use Flatpak. I'll try
to publish more information about this when it goes into production use.
> > I'm sure the costs and benefits are different for your use case, but as
> > a data point: game-data-packager used to have an ad-hoc shell script per
> > supported game. It has been *much* nicer to maintain since its redesign
> > as a Python program that reads declarative recipes.
>
> I've ever thought about providing a Python interface in duprkit, such
> that a .durpkg can be either
> (shell script) + (HFT part)
> or
> (python script) + (HFT part)
Perhaps you were misunderstanding my point. The important part for me was
not the use of Python rather than shell (although writing robust Python
is certainly much easier than writing robust shell): the important part
is that the recipe is declarative, without executable code (although a
few recipes do reference executable code in the game-data-packager "core"
that was added specifically for a particular game or family of games).
game-data-packager could be rewritten in Perl or C or Rust and it would
not change the contents of the recipes. I think that's a very powerful
design principle, also seen in projects like Meson, systemd and Upstart
(but not in, for example, Scons or LSB init scripts).
smcv
Reply to: