(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@redhat.com Reply-To: Discussion of Development and Customization of the Red Hat Linux Installer anaconda-devel-list@redhat.com Organization: Red Hat To: anaconda-devel-list@redhat.com
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
On 09/21/2011 03:21 PM, Lennart Poettering wrote:
(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@redhat.com Reply-To: Discussion of Development and Customization of the Red Hat Linux Installer anaconda-devel-list@redhat.com Organization: Red Hat To: anaconda-devel-list@redhat.com
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.
My misunderstanding. "Maintain it in sync" made me assume it was just a 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.
We already write that string to /etc/sysconfig/clock, which is shell syntax, but it's still there.
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.
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?
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?
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.
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.
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.
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.
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.
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?
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.
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.
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'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.
Seriously? Thanks, I appreciate that.
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. 2) Build up s-c-date or some other tool that can centrally own whatever time and date stuff the distribution needs. 3) Stop creating more time and date files in /etc, I think we have enough.
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:
- 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.
- 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.
- 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
On Wed, 2011-09-21 at 23:43 +0200, Lennart Poettering wrote:
On 21.09.2011 22:39, David Cantrell wrote:
- 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,
We already write out these files with the first change initiated by the user. This is already decided and coordinated across all distros which use systemd.
We would like to have Anaconda to set up the initial file to prevent the telling "Unknown" output at the very first config setting. Please consider adding the file.
Thanks, Kay
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.
Under which circumstances does systemd change /etc/localtime? Is this something anaconda can just call so that /etc/timezone also gets written out? We've pretty thoroughly bought into using systemd in the installation environment, so we could conceivably just call into whatever you're doing already.
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.
We have tools that modify authentication parameters, users and passwords, the firewall, and so forth. It seems reasonable to also have something similar for timezone.
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.
We've been spending a lot of time doing what people want - making anaconda less special. Part of this is removing knowledge that only anaconda has. This timezone thing is a prime candidate. It doesn't matter what we were doing in the past. If we're having to change things now, we might as well do it right and make anaconda not have to know about these details.
Please don't work against the unification of Linux.
Insulting the people who can help you with baseless accusations and ridiculous hyperbole is not a wise plan. This isn't fedora-devel-list. Please keep statements like this to yourself.
- Chris
Chris Lumens (clumens@redhat.com) said:
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.
Under which circumstances does systemd change /etc/localtime?
When it's told to, essentially.
Is this something anaconda can just call so that /etc/timezone also gets written out? We've pretty thoroughly bought into using systemd in the installation environment, so we could conceivably just call into whatever you're doing already.
There's a small dbus-activated service that runs; you call SetTimezone() on it with the timezone you want. Similarly for NTP, locale, hostname, etc.
This should be pretty easy to frob in the running install environment; less easy to do in the install root, as the service wouldn't be running there.
Is this currently done: 1) only in the install env (and then copied to the install root) 2) only in the install root 3) in both the install env and the install root separately
Bill
Heya,
On 27.09.2011 22:07, Bill Nottingham wrote:
Chris Lumens (clumens@redhat.com) said:
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.
Under which circumstances does systemd change /etc/localtime?
When it's told to, essentially.
Is this something anaconda can just call so that /etc/timezone also gets written out? We've pretty thoroughly bought into using systemd in the installation environment, so we could conceivably just call into whatever you're doing already.
There's a small dbus-activated service that runs; you call SetTimezone() on it with the timezone you want. Similarly for NTP, locale, hostname, etc.
This should be pretty easy to frob in the running install environment; less easy to do in the install root, as the service wouldn't be running there.
Is this currently done:
- only in the install env (and then copied to the install root)
- only in the install root
- in both the install env and the install root separately
This is an interesting question: the mechanisms are bus activated, and hence probably not fun to use from outside of the actual system. If the anaconda firstboot stuff is the only code needing this functionality it would make a lot of sense to use these mechanisms only after the first boot into the actual system.
Lennart
Lennart Poettering (lpoetter@redhat.com) said:
There's a small dbus-activated service that runs; you call SetTimezone() on it with the timezone you want. Similarly for NTP, locale, hostname, etc.
This should be pretty easy to frob in the running install environment; less easy to do in the install root, as the service wouldn't be running there.
Is this currently done:
- only in the install env (and then copied to the install root)
- only in the install root
- in both the install env and the install root separately
This is an interesting question: the mechanisms are bus activated, and hence probably not fun to use from outside of the actual system. If the anaconda firstboot stuff is the only code needing this functionality it would make a lot of sense to use these mechanisms only after the first boot into the actual system.
We could go down the root of for this sort of configuration, to have it passed as some sort of kickstart/data/whatever to the installed system, which runs a special firstboot.target target on its firstboot, that applies these settings (and then disables itself.) If that data isn't there, you get the interactive firstboot that asks for these settings.
Bill
HEya,
On 22.09.2011 22:41, Chris Lumens wrote:
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.
Under which circumstances does systemd change /etc/localtime? Is this something anaconda can just call so that /etc/timezone also gets written out? We've pretty thoroughly bought into using systemd in the installation environment, so we could conceivably just call into whatever you're doing already.
All systemd does is provide a tiny dbus mechanism service that is used by GNOME3.2, to change timezone/time/NTP and so on. It is easily accessible from all code that can do D-Bus.
It's documented here:
http://www.freedesktop.org/wiki/Software/systemd/timedated
[ As a side note, there are similar tiny mechanisms for locale/kbd settings and for the hostname:
http://www.freedesktop.org/wiki/Software/systemd/hostnamed http://www.freedesktop.org/wiki/Software/systemd/localed
Is that interesting for anaconda as well? ]
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.
We have tools that modify authentication parameters, users and passwords, the firewall, and so forth. It seems reasonable to also have something similar for timezone.
We could probably provide a binary that is simply a client to the bus service. Would that be in your interest? Of coure, if Anaconda is written in Python it's probably much nicer to just invoke the bus calls directly.
Lennart
All systemd does is provide a tiny dbus mechanism service that is used by GNOME3.2, to change timezone/time/NTP and so on. It is easily accessible from all code that can do D-Bus.
It's documented here:
http://www.freedesktop.org/wiki/Software/systemd/timedated
[ As a side note, there are similar tiny mechanisms for locale/kbd settings and for the hostname:
http://www.freedesktop.org/wiki/Software/systemd/hostnamed http://www.freedesktop.org/wiki/Software/systemd/localed
Is that interesting for anaconda as well? ]
Yes, these look interesting. I'll poke around with them next week and see what we can do. Thanks for the link.
We could probably provide a binary that is simply a client to the bus service. Would that be in your interest? Of coure, if Anaconda is written in Python it's probably much nicer to just invoke the bus calls directly.
Having the dbus interface is fine.
- Chris
anaconda-devel@lists.fedoraproject.org
-
Bill Nottingham -
Chris Lumens -
David Cantrell -
Kay Sievers -
Lennart Poettering