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 :)
--
bye,
pabs
https://wiki.debian.org/PaulWise
Reply to: