(Belatedly changing the subject line, sorry for the digression...)
On Sat, 13 Apr 2019 at 09:34:54 +0800, Paul Wise wrote:
> I expected the Flatpak /app directory to also be entirely read-only,
> are there parts of /app that are not read-only?
/app is also (separately) read-only, and points into a separate libostree
deployment. If libostree is like git for OS binaries, then a deployment
is roughly the equivalent of a git checkout, except that it needs to be
treated as read-only, because it's made up of hard links into libostree's
content-addressed object storage. (It can sometimes be OK to write to
it very carefully by using atomic-overwrite to break hard-links, and the
ostree package installs a FUSE filesystem rofiles-fuse that is intended to
optimize this process by only allowing the few operations that are safe.)
I think there's briefly a read/write /app (a tmpfs instead of a libostree
deployment?) during the process of building and installing an app, so
that you can `make install` into it before committing it into the
libostree object storage.
> I might at some point take a look at adding such a mode to flatdeb,
> would you accept having that as an option?
Sure. I probably won't be able to review it immediately, but it's
certainly a mode that's worth experimenting with. The steps I'd suggest
would be:
* build the base tarball, like now (multiple runtimes can share this,
it's basically a debootstrap minbase)
* build a Platform runtime ('runtimes' mode) that contains the leaf
package and all its dependencies (the input file for 'runtimes'
mode can already ask to include arbitrary packages)
* perhaps don't build a SDK runtime? (new --no-sdk option)
* build an app from a manifest file that lists the intended metadata
and the files that need to be copied into /app for export (new mode,
or new options in the input to 'app' mode)
I'm not sure whether people who aren't Collabora staff or customers can
get accounts on our Gitlab, so you might have to clone it elsewhere and
send me email instead of using merge requests for now, but it would
probably make sense for me to move flatdeb's canonical repository to
Salsa when it settles down a bit.
> > The matching SDK runtime that is used to compile apps
>
> I don't know enough about SDKs in the Flatpak world, would they
> contain something like the Build-Depends and their recursive deps?
Normally, when you're building a runtime to be shared by multiple apps,
the SDK contains everything necessary to compile and debug those apps, so
the -dev packages and (optionally) detached debug symbols corresponding
to all the libraries you're interested in, plus compilers and a basic
CLI debugging environment (gdb, strace, valgrind, less, vi). The example
Games runtime in flatdeb is an example of this, very loosely inspired
by the Steam Runtime: it has the build-dependencies of OpenArena, and
it would be reasonable to expand it to have the B-D of some other games
and game engines like darkplaces and ScummVM.
The detached debug symbols in /usr/lib/debug are usually
carved out into an "extension" so that you don't always have
to install them, and flatdeb does that automatically: you get
net.debian.flatpak.Games.Platform and net.debian.flatpak.Games.Sdk
runtimes, each of which is designed to be mounted on /usr, together
with an optional net.debian.flatpak.Games.Sdk.Debug extension that gets
mounted on /usr/lib/debug if installed.
For your idea of building a runtime per leaf package that happen to
share most of their content and get deduplicated by ostree, putting its
complete B-D in the SDK runtime might be excessive (the whole point of
your idea is that we don't recompile the leaf package), but I think a SDK
runtime that contains a CLI debugging environment with might still make sense.
flatdeb also produces a ...Sdk.Sources extension with the source code
(by evaluating the Source and Built-Using fields), to make GPL compliance
easier - this mimics what flatpak-builder does. At some point I'll add
an option to disable this for people who are doing their GPL compliance
some other way (my work project might start taking snapshots of the apt
repository that exactly matches a particular runtime, at which point
the Sources extension becomes redundant and can be discarded).
> > In principle there'd be nothing to stop debos from using something
> > like user-mode-linux as an alternative to qemu/KVM.
>
> I guess you could also use container tools like systemd-run with user
> namespaces (once those are enabled by default)?
My understanding is that systemd-run is not designed for unprivileged use.
If I'm wrong about that, then, yes, debos could in principle use it.
bubblewrap is *not* suitable for this use: it's probably OK for building a
Flatpak app that is a leaf package (and flatpak-builder uses it for this),
but it isn't going to work for building the container that is the basis
for the runtime, because dpkg/apt/the Debian base system expect to be able
to access more than one uid. Because of the restrictions placed on it
by unprivileged user namespaces, bubblewrap maps the calling user's uid
outside the container to a user-chosen uid (normally either the calling
user's uid or uid 0) inside the container's userns, and maps every other
uid outside to /proc/sys/kernel/overflowuid (i.e. 'nobody') inside.
https://github.com/projectatomic/bubblewrap/blob/master/README.md suggests
that it might eventually be possible to use runC for this, unless it ends
up with the same restrictions as bubblewrap.
smcv
