On Tue, Jan 20, 2015, at 06:27 AM, Jan Zelený wrote:
> You are probably right, I might have misunderstood what you actually
> propose. Does it mean that you actually don't require this part to be
> implemented at all and you can go with what's in /var without any
> distribution-wide changes?
Fedora 21 Atomic does work with a current F21 packageset. For example
Docker stores state in /var/lib/docker, and no changes were required to the
docker RPM or or rpm-ostree for this.
(Although an aside, Fedora 21 Atomic also stores docker images in a LVM
volume which means they would need special factory reset handling if the
feature was implemented)
> In other words, do you propose this change to be gradually implemented
> where it makes sense?
Right, on demand. If there's a Fedora RPM that doesn't work with this
scheme and is desirable to use by a 3rd party or by the Fedora Atomic
subproject, we'd engage with the RPM maintainer to figure out a solution.
> Thank you for the additional explanation. Now I think that the problem is
> not in what you want but in possibly ambiguous specification. What I'm
> afraid of is that some people will use this opportunity to push through
> fully transient /var.
There's a commit to OSTree which does make fully transient /var happen out
of the box if the underlying / is read-only:
https://git.gnome.org/browse/ostree/commit/?id=ff6883ca0655ac8844cd783caf6a7
d8815515ba3
Which is pretty nice for some use cases, but definitely not the default =)
At a high level, I do agree this part of the change needs analysis, and
I'm glad you brought it up. In the end I think the risk here is going to
vary a lot per package.
For example, I need to look closely at the alternatives system.
But I certainly don't want to break the traditional install model - among
other things, it's going to be a while before rpm-ostree would be a usable
way to run my desktop, and also packages need to be backportable to older
branches, etc.
Thanks again for the detailed explanation, I really appreciate it :-)
Jan