Heya,
On 21.09.2011 22:39, David Cantrell wrote:
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.
We already write that string to /etc/sysconfig/clock, which is shell
syntax, but it's still there.
Well, but that's Fedora specific, so not really used by anybody.
Please consider this request an attempt to move from a Fedora-specific
file to a somewhat standardized file, in order to unify, standardize our
platform.
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.
I don't buy that. History has shown that things change in Linux a lot.
Remember when everyone thought /sbin/init was a solved problem?
Well, the specific experience with /etc/timezone on the other distros is
that it hasn't changed in 10y, and nobody sees any reason to change it
any time soon either.
It is really not helpful conflating init systems and a trivial
configuration file here like this. This has little to do with each other.
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.
Which would lead to a bad user experience. The possibility of the files
being out of sync is real, in which case why should anyone ever trust
the value in /etc/timezone?
Well, I can only repeat myself: many tools already write that file, and
the effect will be minimal since only config frontends will show
out-of-date data. And on top of that you already said that
/etc/sysconfig/clock is already written by Anaconda, so the "problem"
already exists.
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.
I'm not advocating trying to maintain some level of distinction from
other distributions. I really don't care what the other distributions do
or don't do.
That is not helpful. You should care. Fedora is not an island.
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.
Actually, a lot of people touch that file manually. It's a file. Assume
users will touch it.
Right, so following this logic we shouldn't place a kernel in
/boot/vmlinuz-xxx either, since it's a file, assume users will touch it?
It's a binary file. That's quite a good deterrent: you cannot use an
editor to modify it.
In particular, since the Ubuntu/Debian userbase is bigger then ours it
will be easier and more obvious to understand this, especially for
newcomers.
That's not a compelling reason to make this change.
Oh, right. We should make it hard wherever we can for other Linux folks
to come over to Fedora.
Seriously, you should care about making adoption of Fedora easy for
people from other distributions.
And again, even if the two files get out of sync, the effect won't be
that bad.
But it would be a little bad. This strikes me as one of those changes
where we can't make a decision that please everyone. It's like picking a
reasonable default size for /home during autopartitioning or what goes
in to the default package selection....there's no way to actually make
all users happy. So any change there gains you nothing. You just shift
the displeasure to a different group of users.
Humm, if I google for it I find no complains about the two files even
though DEbian/Ubuntu/Gentoo have been using this since about forever,
and they have a much bigger userbase than we have.
I don't think the issue you raise is real.
> 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.
So what component would own the bug report in that case?
If this is about bug reports, I am happy to take them all. Assign them
to systemd, or any other of my packages. I am happy to take them.
> 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.
But a tool that owns the synchronization of /etc/localtime and
/etc/timezone should exist. Otherwise we get in to problems like we've
had in the past with who owns changes to /etc/hosts, or
/etc/resolv.conf, and so on.
It's a trivial thing, and there isn't really any additional
infrastructure necessary for this, as the tools modifying /etc/localtime
are a few only, and many (the ones which are available on the other
distros too) can write the files already.
You may consider systemd's timedated mini bus service as the
infrastructure you are asking for if you want. GNOME uses that to make
the changes to the timezone, and the bus service will make sure to keep
the files in sync.
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.
Based on your description, /etc/timezone is a file written by numerous
components, so there's no primary owner. That's my concern.
Why is that a concern? The programs that the timezone are multiple, but
not more than maybe 7 or so across the distro. And the tools which also
work on other distros are already capabale of writing that file, anyway.
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.
The time zone string is currently available in /etc/sysconfig/clock and
has been for a very long time. How about systemd grabbing the string
from that if /etc/timezone doesn't exist and writing it out?
It is our intention to use systemd as a vehicle to standardize the Linux
platform. That means that at some places we are gently pushing the other
distros to adopt Fedora configuration files and at other places it
appeared better to us to adopt configuration files used by others
already. In the case of the timezone file we decided to make systemd
follow the configuration files of DEbian/Gentoo/Ubuntu, since it was
simpler, made more sense and was more widely adopted.
Here's what I would like to see with time and date stuff:
1) Do not put *more* code for time and date setting in to anaconda.
Is it that much more, really? here's a deal: remove writing
/etc/sysconfig/clock instead, and things will be shorter.
2) Build up s-c-date or some other tool that can centrally own whatever
time and date stuff the distribution needs.
We are more or less out of the business of building s-c-xxx tools these
days. The focus needs to be upstream on this: and with systemd we have
the mini bus service to keep the files in sync. Except that Anaconda
isn't cooperating with it nicely.
3) Stop creating more time and date files in /etc, I think we have enough.
We didn't invent this file, we just follow a sensible de-facto standard
set by other distributions.
Please reconsider your decision,
Lennart
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
