On Tue, 25.03.14 11:54, juho son (juho80....@samsung.com) wrote: > > On 03/25/2014 04:47 AM, Lennart Poettering wrote: > >On Tue, 18.03.14 02:34, Juho Son (juho80....@samsung.com) wrote: > > > >>This option could changes the default system's time zone. > >>The default time zone is /etc/localtime. If we want to use > >>the specific path, we could use this option. > >I agree with the others on this thread, this really looks like nothing > >we should support upstream. /etc is the place for configuration. If you > >decide to mount it read-only (which is absolutely valid), then > >configuration is ready-only, and that's the exactly the effect that > >mounting /etc read-only should have, so playing games with redirecting > >this sounds misleading. > > > >Lennart > > > Yeah if we decide to use the /etc to read-only, we should use like that. > but we could modify some configurations > like group, passwd, smack, mtab and localtime in runtime. > So we use links for that in read-only. > You already knew the systemd's configurations are in /etc/systemd. > It is very valid that /etc is read-only for protecting it. > So system configuration with link and read-only could give satisfaction for > protecting and supporting legacy module needed modification in runtime. > So I want to say I think that (link with read-only) is useful. > so put the "/etc with link and read-only" conversation beside. > > I want use the timedated in my system. > timedated only use "/etc/localtime" for system' timezone. > So I should modify timedated source code for my system. > That's why I suggest the option to configure. > Someone to use like me need that option or configuration. > Some system use TZ environment variable for specifying. > and if the TZ does not have value, > default timezone is /etc/localtime or /usr/local/etc/localtime. > In GNU C library, that depends on configuration in installation. > First time, I considered the build configuration like > "--with-timezone-path=". > but I think the option submitted is better after I see the rootdir > option in other. > So please consider it with flexible perspective for alternative system.
I am not convinced this is something we should support upstream (this shouldn't stop you from changing this downstream though...). But I think there's no point in introducing multiple levels of /etc and advocating this from upstream... Sorry, Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
