On Fri, Jun 13, 2014 at 6:37 AM, Colin Walters <walt...@verbum.org> wrote: > On Fri, Jun 13, 2014, at 05:36 AM, Colin Walters wrote: > >> My high level takeaway right now is that this looks OK for nspawn >> containers, but it's not clear to me it's viable or right for the host >> OS, at least for general purpose systems. > > That was wrongly stated - basically I'm just skeptical of seeing an > empty /etc on general purpose systems in the next few years, at least > without lots of non-upstream patches and hacks. A good example is this: > https://github.com/coreos/baselayout/commit/98c6211c45c8c53d84df1657776314cc5f5f9ec1
For what its worth, in my efforts to make CoreOS boot with a completely empty root filesystem I found that the changes required were usually not too dramatic. Fixing many packages, like sudo, just amounted to shipping different config files and adding --sysconfdir=/usr/share to ./configure at build time. For dbus it only takes that configure option plus a update to session.conf and system.conf to support both /usr/share/dbus-1 and /etc/dbus-1 for configs: https://github.com/coreos/coreos-overlay/blob/master/sys-apps/dbus/files/dbus-1.6.x-add-explicit-etc-path.patch Where new code is required it is similarly not very complicated, to support reading account information, services, hosts, and other nss data files we have a small project that is just a strait-up copy of the files nss module from glibc with some hard coded paths changed to configurable macros. https://github.com/coreos/nss-altfiles So working through all these details is a damn tedious task and I don't doubt it could be years before we and others get around to getting good support for reading configuration from both /usr and /etc into upstream packages. The good news is that while we bang out the best way to implement this the changes aren't any weirder than the patches and hacks that distros typically have to do when integrating packages. As a side note, regardless of whether an empty /etc is actually viable or not the more packages that support gracefully dealing with configuration in both /etc and /usr the fewer files there will be in /etc that are in the awkward position of being managed by both users and packages. rpm and dpkg's behavior of just picking one and backing up the other or gentoo's scheme of forcing users to wade through 3-way diffs are all pretty terrible. If packages did their best to avoid installing files to /etc, giving users exclusive control over that space, everyone wins. :) _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
