Re: App image experiments

[Alexander Larsson <alexl redhat com>]

On tis, 2013-05-07 at 23:07 -0400, Colin Walters wrote:

> The core issue is we don't want to toss out centralized management.
> Concretely for example, an admin should be able to get a unified view of
> all of the gsettings schemas, for the system and for each app.
>
> But here's what's making my head spin a bit - assuming we have per-user
> application installation (and we should), does the system support having
> an admin construct the schema search path just for that user?  Like:
>
> # whoami
> root
> # gsettings list-recursively --for-user=walters
> ... 
>
> ?  Or would we just say that in order to get a view of the environment
> for user walters, you just log in via e.g. "runuser walters", and run
> gsettings there?  The downside of that is - how would you do mandatory
> controls on a per-user installed application?  You'd be putting a key
> into /etc/dconf that the system dconf is unaware of.  Maybe it won't
> complain...

I think the configuration search path should always start with the
global mandatory settings end up in the global default settings, which
the admin can easily see. However, I'm not sure how important it is for
an admin to get a view at exactly the settings of a particular user.
Using something like runuser seems fair enough.

I don't think there is an issue putting "unknown" mandatory keys in,
because the mandatory stuff is done at the dconf level, not the
GSettings level, and dconf is a raw store, without any knowledge of key
name/types or schemas.

> And here's an additional level of complexity - say we want to do
> something Android-like and isolate applications from each other.  Then
> the system will need to be able to construct the Search Path for pairs
> of (Application, User), as well as the merged view of all applications
> for a given User.
>
> Other projects trying to move forward in this area just have per-user
> Search Paths, effectively set on login.  That's not too terrible as long
> as the parts that need to be live monitored are.  This is really what
> the XDG basedir allows now.   

I think this was basically what we ended up with at the hackfest. We'd
have some runtime tool that auto-extracts and manages per-user XDG
basedir prefixes based on the set of "installed" apps. It needs to keep
track of what files belong to what app, handle conflicts, have snippets
for e.g. rebuilding mime dbs, etc.

> Anyways; it's kind of tempting to just set up a builder that drops out
> zip files or something that unpack per-user into ~/.local to at least
> have *something*...

Hehe.