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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
