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. I've looked at the approach ubuntu uses, which is quite ugly but does fix the main problem and also fixes a base-config wishlist bug by using os-prober to work out whether to use GMT. I don't feel very comfortable applying that patch as-is though. Some of the questions I'm considering: - Do we want tzsetup to be useful to users after the install> Dropping it and only including crufty old tzconfig (which should have died years ago) in Debian base would rather suck. However, many users will be using GUI time zone setup tools after the install. Also, tzstup is already not as useful after the install as during the install, since users cannot easily use it in the much nicer mode it enters if it has country code information. This is kind of a downside of merging countrychooser into localechooser, since a user will almost never want to change locale after the install, but selecting first a current country and then timezone based on that is a more common need. On a broader level, Debian could be much more friendly to roaming laptops. Fiddling with tzsetup, proxies, sources.list, ~/.georc, etc on the airplane on your way to $NEW_LOCATION is a pain. But that's out of scope for d-i.. - Should d-i/base-config handle clock setting? I tend to think not -- there are too many other ways to do that. The base-config BTS proves though that users expect this to be part of the installation experience, at least if the install ever shows them the current value of their clock. So if we don't want to be dragged into setting clocks, we need to avoid displaying them. Which is difficult when it comes to choosing whether the clock is set to GMT.. - 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? 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. 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. Putting that into tzsetup gets even further away from what the program should do, so at least splitting it into a separate program seems like a good idea. - Should tzsetup run before or after the base system install? I think that we want to ask as many questions as we can before the base system install, not afterwards. However, tzsetup relies on /usr/share/zoneinfo/ to generate timezone lists for some countries. It could still run before there is a base system, if we "compiled" that info down into some debconf templates instead of generating them on the fly. This would also make it all translatable. - Should tzsetup be in a d-i udeb, or called by a udeb? Of course this depends on some of the earlier questions. If it's in a udeb and we also want it usable after the install, we'll need it in a deb too, and we'll have to be careful to make it work on both d-i and debian. If we want to configure the timezone before the base install, we need it in a udeb. Based on that, one way I can see to do it is: 1. Split GMT selection out into a clock-setup udeb, which runs after partitioning (because it needs os-prober), and tries to guess at whether or not to use GMT, etc, etc. This could also handle setting the clock, although that would not be its main purpose, and should be avoided if possible. 2. Move tzsetup out of base-config and into a udeb, which can run standalone with only the user's country as an input, and which contains all the timezone choices for different countries. Wait to see if people miss having tzsetup in base. -- see shy jo
Attachment:
signature.asc
Description: Digital signature