Web lists-archives.com

Re: PPAs (Re: [Idea] Debian User Repository? (Not simply mimicing AUR))

On Fri, Apr 12, 2019 at 3:27 PM Simon McVittie wrote:

> 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.

I expected the Flatpak /app directory to also be entirely read-only,
are there parts of /app that are not 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
> the container.

It sounds like my idea might be a viable way to generate automatically
Flatpaks directly from leaf Debian packages then, thanks for the info.
I might at some point take a look at adding such a mode to flatdeb,
would you accept having that as an option?

> flatdeb installs apt/dpkg/essential, but then deletes apt, dpkg and ...

Yeah, I noticed that so I was glad when mmdebstrap's sub-essential
stuff came along.

> 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?

> 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.

That sounds like a much better design.

> 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)?

> 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
> host system.

Cool, thanks for the information :)