On Mon, May 26, 2003 at 06:40:42PM +0700, Alexey Morozov wrote:
> Ну, в общем, наверное, можно использовать схему, когда при выборе
> таймзоны (в инсталляторе) соответствующий файлик просто копируется
> в /etc/localtime, и /etc/init.d/clock не пытается даже использовать
> данные из /usr/share/zoneinfo...

$ ls -l /etc/localtime 
-rw-r--r--    1 root     root          815 Мар 23 21:14 /etc/localtime
$ rpmquery -lv glibc-core |fgrep /etc/localtime
-rw-r--r--    1 root    root              815 Мар 23 21:14 /etc/localtime

Я не знаю, какая программа портит /etc/localtime.
Боюсь, что installer.

> Но тогда автоматически встает вопрос корректных апдейтов этого файла
> при апдейтах glibc-timezones.
> 
> Я так вот вижу возможные пути решения проблемы.
> 
> > Только если
> > is_yes "$HWCLOCK_SET_AT_HALT"
> В случае домашних машинок без внешних ntp-серверов это единственный
> более-менее приемлемый способ поддерживать системные часы. Если верить

Значит, надо заменить на
if ! is_no "$HWCLOCK_SET_AT_HALT"

> докам на hwclock, величина убегания цмосовских часов более-менее постоянна,
> так что и бороться с этим тоже можно... Но тогда встает во весь рост вопрос
> DST. Наверное, можно где-либо сохранять последнюю использовавшуюся таймзону,
> и, с одной стороны, при апдейте glibc-timezones копировать в /etc/localtime
> нужный файлик (по правилам config(noreplace)), а с другой, при "перещелке"
> DST переводить соответственно хардварные часы. Переводить их нужно, потому
> что использоваться это вся конструкция (часы не в GMT, отсутствие NTP) будет
> преимущественно на дуалбутных домашних машинках, а Windows (TM) часы
> переводит. Ну, в общих чертах вот так вот, но но на оформление этого всего
> аккуратно меня сейчас не хватит.

У кого хватит?


--
ldv