Re: xdg-app questions

[Alexander Larsson <alexl redhat com>]

On mån, 2015-01-19 at 08:42 -0500, Matthias Clasen wrote:
> Hey Alex,
>
> thanks for merging all my branches!
>
> A few questions I had while working on them:
>
> - Are the ipc and network keys 'reversed' ? ie doesn't a new namespace
> for these make things more constrained ? for all the other keys, a
> value of 'true' means 'poke a hole'...

Not sure what you mean here. 

ipc=true means we share the ipc namespace with the host. In practice
this means that sysV ipc (e.g. shared memory) works between the app and
the host. If this is not specifiec then XShm will not work for instance.
A value of true here is indeed a "poke a hole" operation.

network=true is similar in that a value of TRUE means sharing the
network with the host. If false, then the app only sees a single
loopback interface. Additionally abstract unix sockets are not able to
access services in the host, which means we can't reach the session dbus
(until we fix this in the session to not use abstract sockets).

> - Is there a strong reason to have separate app and runtime namespaces
> in the filesystem ? On the other hand, it is not entirely clear to me
> how system and user level interact when it comes to this - will a
> user-installed app use a system runtime ? Will it prefer a system
> runtime over a user runtime ?

I didn't mean for the two to be aggressively separated, the current
setup just kind of happened because I want it to be fully possible to do
user-based install of both runtimes and apps. I think we should allow a
user-installed app to use a system-installed runtime and vice versa.
Exactly the best way this would work is not super clear, but it seems
natural for the user installed thing to override the system one.

> - Why are we pruning so agressively ? One of the selling points of
> ostree is 'instant rollbacks' - you loose that if you prune away all
> the old versions... I wonder if we should have a more relaxed policy
> for pruning. This also made the --commit support harder to write - I
> have to pull the old commit from the server, because it will never be
> present locally.

True. On the other hand, the common case will be a user running always
the latest version and having regular updates to the latest version in
the background. If we don't prune things then that can easily cause a
lot of unnecessarily used diskspace.

Part of the problem is that there is no natural way to "delete" a single
ref during upgrade or uninstall. You can only do a repo-global GC
operation. I guess we could add refs to older versions we want to
support rollback to, to make them not be GC:ed. Not sure what the best
UI for this would be though, as it seems a bit low-level.

> - Wrt to code organization - was there some idea to keep direct ostree
> calls in xdg-app-dir.c/xdg-app-utils.c and make the builtins just use
> those, or anything goes ?

Its more like anything goes, but larger chunks of support for the ostree
stuff (especially things that is shared between builtins) should go in
xdg-app-dir.c.

> - Wrt to api naming - how do you feel about going with the flow and
> calling remote repositories 'remote' in the xdg-app commandline ? both
> git and ostree use that terminology, and avoiding gratitious
> differences would be good.

Its called "repository" in yum and the like though. But that perhaps
referencing that is just confusing. Anyway, i wouldn't mind switching
this to remote.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl redhat com            alexander larsson gmail com 
He's a scarfaced Amish vagrant with a robot buddy named Sparky. She's a 
sharp-shooting gypsy doctor in the witness protection program. They fight 
crime!