Re: PPAs (Re: [Idea] Debian User Repository? (Not simply mimicing AUR))
- Date: Fri, 12 Apr 2019 08:26:33 +0100
- From: Simon McVittie <smcv@xxxxxxxxxx>
- Subject: Re: PPAs (Re: [Idea] Debian User Repository? (Not simply mimicing AUR))
On Fri, 12 Apr 2019 at 10:49:57 +0800, Paul Wise wrote:
> Is there any reason that making /app a
> symlink to /usr (or a directory containing only links to /usr)
> wouldn't work inside Flatpak packages?
Flatpak treats /usr as immutable (with the exception of mounting
"extensions" on pre-prepared empty directories) and mounts it read-only in
the container. If it didn't, it wouldn't be able to use content-addressed
storage (the storage can't be content-addressed if the content changes).
In the usual way to use Flatpak, with a shared runtime for a family of
related packages like "the GNOME apps", apps would end up accidentally
or deliberately modifying each other's runtimes if they weren't read-only.
If the user-facing leaf package is really installed in the runtime, with
a different runtime for each user-facing leaf package, you're right that
the Flatpak app could mostly contain symlinks into /usr. A few metadata
and integration files that get "exported" to the host system (such as
.desktop files and icons) would have to be copied instead of symlinked,
because the host system needs to be able to read those without entering
> I had planned to do this using
> mmdebstrap, which now offers installation of Debian systems that don't
> have apt/dpkg/essential, by using the new dpkg root stuff.
flatdeb installs apt/dpkg/essential, but then deletes apt, dpkg and
a few other parts of essential/important that make little sense in a
single-user container (such as mount, adduser, passwd) with dpkg --purge
--force-depends --force-remove-essential before preparing the Platform
runtime that is used to run apps. The matching SDK runtime that is used
to compile apps still has the full set of packages.
It also deletes perl-base if perl isn't installed, and python-minimal
if python isn't installed.
> Hmm, last time you presented flatdeb, it wasn't using debos, how does
> debos get used in flatdeb now?
Instead of using sudo or ssh to a remote (usually virtual) machine to
get root so that it can run debootstrap and dpkg, flatdeb now runs debos
on the local machine. This means it's root in debos' temporary qemu VM,
and doesn't need privileges other than /dev/kvm access in the host system.
In principle there'd be nothing to stop debos from using something
like user-mode-linux as an alternative to qemu/KVM.
> It might also be interesting to start importing the standard Debian
> installations into an OSTree archive
One per desktop task, plus one for the Priority >= standard default
CLI installation, would be quite a lot of data but could be good for
bisecting, yes. I'd suggest doing this with debos, which has built-in
support for committing trees to libostree and doesn't need root on the