On Wed, Aug 8, 2012 at 6:51 PM, Lennart Poettering <[email protected]> wrote: > On Tue, 07.08.12 00:31, Shawn Landen ([email protected]) wrote: > >> keep other method for now, consider dropping later. >> >> Supporting relative links here could be problematic as timezones in >> /usr/share/zoneinfo are often themselves symlinks (and symlinks to >> symlinks), so this implamentation only only support absolute links. > > Hmm, I am not entirely sure this is really the best thing to do. Always > requiring a symlink for /etc/localtime breaks a couple of things: we > can't just bind mount things over in an nspawn container,
Just mount the symlink pointing to /usr/share/zoneinfo/ in the container, or possibly to a copy of localtime stored the container's /run, if there isn't anything in the container's zoneinfo? > embedded > devices have to ship /usr/share/zoneinfo/, which is probably something > they might want to avoid. I wouldn't see much of a problem if we can't determine the time zone text in exotic and custom setups. If we don't have stuff available to link to from /etc, we just leave it alone. > So, dunno, I think this is something to think about first, discuss the > pros and cons. I see that just having this as symlink is much simpler, > no doubt, but does it have more benefits? And possibly more > disadvantages? Stuff in /etc invites to manual edit and "administration". Two files, with very different names, describing the very same thing, which need to be in sync, are so bad, that in the end, there is no real question here, I guess. :) Kay _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
