This page is obsolete
The forward configuration below is implemented. But I am no longer viewing everything in /etc as a bug - what we have now is fine.
Old page
The semantics we want for upgrades is that current system configuration is preserved. A desirable feature is that on downgrades, one still has new configuration applied. Futher desirable features would be nice 3-way merging user interface for system administrators.
Here's what's implemented currently:
Configuration propagates forwards
- Every /ostree/deploy/REV gains a corresponding directory /ostree/deploy/REV-etc
- When deploying a tree, we first compare "current etc" with "current-default etc", generating a list of MODIFIED files
- Then compare the "current-default etc" with the "new etc", gathering a list of DELETED, and NEW
- MODIFIED files are those which the admin affected in some form (deleted, created, changed)
- DELETED and NEW have obvious definitions
- Compute the intersection MODIFIED-DELETED and MODIFIED-NEW. If we were to support a three-way merge, these
- file sets would be candidates to display this way. However for now, let's just resolve them in favor of MODIFIED.
- Check out a new tree NEWREV-etc. Delete DELETED. Copy over MODIFIED and NEW.
The high level semantics here are, as the title says, "configuration propagates forwards". In other words, when you upgrade, any configuration changes you have made in the old tree are applied to the new one. However, if you then boot into the new tree, modify things, and then later reboot into the old tree, the changes are NOT applied.
rm -rf /etc/*
While the above model works, we still carry around a huge amount of defaults in /etc. The system would be much improved if we move defaults into code, and make booting a client OS with an empty /etc possible. Now, some files in /etc/ should be generated by an installer, such as default keyboard layout, but it should be possible to delete all files in it and have the OS boot (and for keyboard layout, GDM would provide the ability to choose).