(Replying to a mailing list mail in a forwarding from Ales, sorry for that)
On 06.09.2011 08:29, Ales Kozumplik wrote:
-------- Original Message --------
Subject: Re: [f16-branch] Write human readable timezone information to
/etc/timezone.
Date: Wed, 31 Aug 2011 09:39:20 -0400
From: David Cantrell <dcantrell@xxxxxxxxxx>
Reply-To: Discussion of Development and Customization of the Red Hat
Linux Installer <anaconda-devel-list@xxxxxxxxxx>
Organization: Red Hat
To: anaconda-devel-list@xxxxxxxxxx
On 08/31/2011 06:52 AM, Ales Kozumplik wrote:
This is to unify this basic config file with other distros. systemd is
made to
maintain it in sync with /etc/localtime.
If systemd maintains the symlink, why can't it create it when it doesn't
exist? Systemd seems to be treating /etc/localtime as authoritative in
this case.
Symlink? There is no symlink.
The new file /etc/timezone is a one line text file with the time zone
name. It has been used like this on Debian, Ubuntu, Gentoo. And that for
a very good reason: because otherwise getting a textual description for
the current zone is really messy, since you need to iterate through
/usr/share/zoneinfo and look for the file that is identical to
/etc/localtime. That is slow, fragile and massively IO intensive.
systemd whenever it changes /etc/localtime will also write /etc/timezone
to the right value. All I am asking here is that anaconda as the initial
tool that writes /etc/localtime does the same.
f = open(instPath + "/etc/adjtime", "w")
f.write(lines[0])
f.write(lines[1])
The problem I have with these sorts of patches are that anaconda now
owns the initial creation of this symlink. What happens when the
symlink has to move, change, or otherwise be modified in the future? I
guarantee you that the group making that decision will not communicate
it with us and we will deal with it in a reactive manner.
There is no symlink. And it won't move. We are just basically copying
here what Debian/Ubuntu/Gentoo have been doing for ages for a very good
reason. They didn't have to change the file in the last 10y or so, and I
see very little for us to make any similar changes. This isn't really
anything new. It's just following an established de-facto standard where
we were basically the only ones who didn't follow it.
This is very unlikely to change anytime soon.
And even in the worst case: since /etc/localtime is authoritative the
effect of /etc/localtime and /etc/timezone being out of sync is minimal.
Configuration frontends might default to the wrong setting, but that's it.
So I always ask myself if anaconda really needs to own the creation of
this symlink or if it can be placed in another component?
It's no symlink. And the thing is that nobody else can fill in that file
efficiently since it requires iterating through /usr/share/zoneinfo. It
must be the tool which writes /etc/localtime that also writes
/etc/timezone. Since it has the right information anyway.
The bug indicates that systemd is pushing for common files like this to
avoid having applications scour /usr/share/zoneinfo to get a human
readable name for /etc/localtime. Why not have systemd just do that at
boot up?
It's an expensive IO-intensive operation, and we want to boot fast...
Doing that at every boot is ridiculous.
It's a trivial operation if everybody who writes /etc/localtime also
writes /etc/timezone at the same time. Most tools which are portable to
other distros do this already anyway. Anaconda currently doesn't, but it
would be great if it did. Like the Debian installer does, or the Ubuntu one.
Note that a major reason to do this change is compatibility with other
distros, there's no need here that we cook our own soup, and distinguish
ourselves from Debian/Ubuntu/Gentoo.
It's more efficient, more descriptive to write /etc/timezone whenever
you write /etc/localtime. It's also helps unifying the various Linux
platforms out there.
> Will users know to update /etc/timezone when they update
/etc/localtime?
I am pretty sure the fewest people change that file manually, and
instead use some kind of tool for it. Since /etc/timezone is a de-facto
standard on many Linux distros most of those tools already know how to
write those files.
In particular, since the Ubuntu/Debian userbase is bigger then ours it
will be easier and more obvious to understand this, especially for
newcomers.
And again, even if the two files get out of sync, the effect won't be
that bad.
> Or will some users think they can change /etc/timezone
to change the timezone and leave /etc/localtime alone and then wonder
why things don't work?
Things will work, since only /etc/localtime is authoritative and is used
by the glibc. if /etc/timezone is out of sync the worst that happens is
that for example GNOME's tz configuration UI shows you out of date
timezone info.
> Perhaps system-config-date could offer a Python
library, C library, and command line tool to look up /etc/localtime and
print out the human-readable name?
Nah. I am sorry. We don't need a library for this, especially since that
would be used on Fedora only and nowhere else.
In short, I do not think this is a thing anaconda should own.
It's nothing anaconda should "own". it's just a file that anaconda
should write, when writing /etc/localtime. The file is currently ghosted
and owned by systemd, but could be moved to setup.rpm or
filesystemd.rpm, too, doesn't really matter.
So, please, here again the reasons why we want this:
- It makes querying the local timezone for presentation in configuration
tools easy and efficient at minimal IO. The previous way to determine it
was highly IO intensive and ugly to work for.
- It's an accepted de-facto standard used on many other distros. Unifies
the Linux platforms.
- Already implemented in many tools that can set the timezone. Major
missing tool is basically Anaconda.
- Keeps our stack simple, since we need no complex algorithms,
libraries, or other complexities that need maintainance.
Please don't work against the unification of Linux.
Lennart
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
