On Mon, Jan 19, 2015, at 07:02 AM, Jan Zelený wrote:
I have hard time figuring out what exactly is the purpose of including the factory reset feature in your proposal. No offense but unless I'm missing something, it seems to me that you are trying to solve some of ostree problems in the rest of the distribution rather than in ostree itself.
I wouldn't say ostree problems exactly. I certainly could change ostree to write to /var. But I think the benefits of it not doing so are worth the change in terms of getting a much cleaner separation between what's owned by the OS and what's user data.
I think this part of the proposed change has implications as severe as those the infamous UsrMove had. And from what I can remember, some of us spent another two releases fixing that up.
Yep, I too made changes for UsrMove.
In this particular case, I foresee problems with all databases (they store data in /var) and web servers (/var/www). For me personally the most immediate blocker is the rpm stack which stores its data in /var on multiple different levels.
Storing data in /var is fine!
Even if we consider something as unimportant as metadata cache, re-downloading it because of transient /var is not something our users will be happy about.
Hmm, there may be confusion on this, which is understandable because documentation is very thin. This isn't about making /var transient by default. In the default OSTree model it's fully persistent. It *can* be optionally transient, or reset explicitly.
All in all, I'm rather against this part of the proposal. In my opinion, ostree should take /var as it is now instead of re-designing it.
Does the above help to address your concerns?
If there is a strong demand for the factory reset feature, it should be proposed, decided and implemented separately.
Fair enough, again to be clear this is only partly about factory reset; it's also about making upgrades more reliable by having it be clear who owns data and when it's modified, which is why the ostree model uses it.