On Saturday 23 July 2005 19:13, Joey Hess wrote: > Since at least two derived distributions are struggling with the > problem of time zone setup happening in the middle of base-config, > after daemons are started etc, I'd like to move this into the first > stage of the install. The current situation is sub-optimal for Debian as well. > Some of the questions I'm considering: > > - Do we want tzsetup to be useful to users after the install> There is a danger in that anyway. Some packages (like chrony) take the value of $UTC in /etc/default/rcS when they are first installed. However, if you change $UTC, the new value is not automatically applied in these other packages. Having a tzsetup kind of implies that all depending changes will be taken care of as well. Just changing the timezone is probably safer, but changing $UTC after initial installation should go with a big warning. > - Should d-i/base-config handle clock setting? See below. > - Should tzsetup handle GMT selection? > > We need GMT selection / autoprobing during the install, but after > you've installed, switching your hardware clock to/from GMT is a > rare thing (unless you remove windows or the install got it wrong). > > tzsetup's GMT selection mode is hidden behind a command line switch > anyway. Does anyone know to use it? Is editing /etc/default/rcS > just as good? See earlier comments. > If GMT selection is moved out of tzsetup then we can more cleanly do > it during the install, based on os-prober, etc. We can also cleanly > skip it on platforms where it does not make sense, removing the > current hack to skip it on s390, and possibly skipping it on other > arches where GMT is always used. Just drop the udeb for those > platforms. You mean "if some kind of Windows present then set to local time"? That's a fairly wild assumption... What about ppl who had Windows on their system but have deleted it as part of the install? Their clock will probably be set to local time. I guess in that situation being able to set the clock would actually make sense... The same goes for new systems (just out of the shop). There's no way of knowing what the clock will be set to. Hardcoding to GMT for some platforms does make sense IMO. > base-config's bug list indicates that users find GMT selection very > confusing, and so it needs to be redesigned anyway. Autodetection is > best. When autodetection fails currently the best method I know of > is asking the user to chose between > "$TIME_WITH_GMT_OFFSET, $TIME_WITHOUT_GMT_OFFSET, neither", > where "neither" would probably need to involve a clock setting tool. That seems like a nice solution. Another option could be to cascade the questions: - assume either local or GMT; ask "is this the correct time" - if no, assume the other option; same question - if no, ask whether user would like GMT or local and ask to set time (May be hard to preseed though; although just preseeding GMT vs local should do: skip all dialogs if that's set.)
Attachment:
pgp6SXkC813tk.pgp
Description: PGP signature