> I was thinking, is it a general stated aim that we should be able to > boot with an empty /etc? I know this isn't true today, but with > appropriate effort is that where we should be aiming?
I have been thinking about this too, and I am even planning on doing some experiments with this. Currently there are a couple of issues: - Some software just fails if they can't read there config file - Most software does not allow for a separate "distribution" and "local" configuration like systemd does - A lot of software does not have any sensible default behavior when there config file is missing. - Some files are needed quiet hard (passwd, group, shadow ,...) The first three should be fixed upstream. The last point is something i would fix with a systemd generator overriding default.target with setup.target if one of these files are missing. > I guess the same should be true of /var too probably (i.e. packages > should be able to cope with initing themselves on first use and not rely > on doing it at package install). I personally think /var is easier than /etc, since most programs already do there initing partially, the only problem is that they don't create there own directories so they fail with an empty /var. But this can easily be fixed using systemd-tmpfiles. There is on my system only one problem in /var: rpm (which if it depended on me belongs in /usr somewhere) Once both /etc and /var can be empty, the only things needed to boot a new machine are a kernel, /bin, /lib and /usr. This would also mean that (together with /bin, /sbin and /lib being symlinks) all packages except those involving /boot should be contained within /usr (which can be ro during normal operation) Simon PS: nice to know other people are thinking in the same direction _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
