According to the Gentoo Handbook, the user should do the following during gentoo installation: # ls /usr/share/zoneinfo (Suppose you want to use Europe/Brussels) # cp /usr/share/zoneinfo/Europe/Brussels /etc/localtime (Next set the timezone) # echo "Europe/Brussels" > /etc/timezone The two steps seem to be redundant on the first sight but then you realize it's the first one that's doing the work and the sense of the second one can be disputed. All in all I believe there should be a single command to set the timezone. Feel free to move this ticket to documentation if the system already supports that and please change the handbook so that a straightforward solution is used.
Also, I think it's much better to use a symlink than to copy a data file, see: ln -sf /usr/share/zoneinfo/Europe/Prague /etc/localtime
(In reply to Pavel Šimerda from comment #1) > Also, I think it's much better to use a symlink than to copy a data file, > see: > > ln -sf /usr/share/zoneinfo/Europe/Prague /etc/localtime We've had that discussion already and it was decided to move from symlinking to copying. The Handbook was changed to reflect that. Please introduce this issue on the gentoo-dev@ mailing list instead.
I'm afraid the answer only covers the additional comment, not the original report. Also I'm curious whether it's common to close bugs in favor of mailing list postings.
we could always string together a bunch of commands with &&, or write big shell scripts to do the work, but it's simpler & better to break the process down to the individual elements.
I'm sincerely sorry for reopening the second (as well as the last) time. I believe that when I take the time to report a documentation issue, that my report deserves at least an answer to the point. None of the two answers seem to be relevant to the reported issue, in my opinion. Please let me rephrase the description to avoid further misunderstandings: http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=6#doc_chap4 1) The first timezone setting step is known to configure glibc and possibly other libraries and software to use a specific timezone data. The comment doesn't really say what's going on given that there's another command for setting the timezone following. # cp /usr/share/zoneinfo/Europe/Brussels /etc/localtime (Next set the timezone) 2) The second timezone setting step writes the timezone name in a file. I haven't seen it on other systems and the handbook doesn't indicate what is it good for. (Next set the timezone) echo "Europe/Brussels" > /etc/timezone 3) Staying with the second command, the comment “next set the timezone” is misleading at the least, as it's the previous command that's known to set the timezone, not this one. Gentoo is the very last system I would expect to do copy-paste black magic with. If /etc/timezone serves a purpose, it should be known (I couldn't find any sources so far). If not, the step should be simply removed. But whatever is the final solution, I don't think it's helpful to have misleading comments in the documentation. The uncertainty about /etc/timezone is the reason I didn't originally file the bug with Documentation. If you're going to direct me to the mailing list, please also provide some link to information about which issues shouldn't be filed with bugzilla so that I can do better in the future.
I've added a blurb about the differences; we can't give a simpler command though, that needs to be provided by the release engineering team (or other team) if that is deemed necessary (like an "eselect timezone" method). Considering this is only about one or two commands, I don't think this is worth the effort.
(In reply to Sven Vermeulen from comment #6) > I've added a blurb about the differences; Much better, now, thanks! What's written there may not be entirely true as it doesn't seem any applications except (Debian) timezone selection tools uses that but we can live with that :). For anyone interested: http://www.debian-administration.org/article/213/Changing_the_timezone_of_your_Debian_system > we can't give a simpler command > though, that needs to be provided by the release engineering team (or other > team) if that is deemed necessary (like an "eselect timezone" method). I don't think there's any value in wrapping those into a single command. It would just be nice to get rid of the configuration redundancy in the future and actually need just one of the commands. But that would be better handled upstream first.
Sven, I'm afraid that your change is not correct. The /etc/timezone is read by the pkg_config function within sys-libs/timezone-data (see [1]), and it is important that it is set up properly. In short, there are two conflicting requirements: a) Update /etc/localtime whenever the underlying TZ file changes, i.e. on update of the timezone-data package. This *can* be accomplished by a simple symlink. b) Make it possible to function with /usr on a separate partition. This means that if /etc/localtime was a symlink to /usr, then stuff started prior to /usr being available would get wrong TZ data. Maybe the best would be to have the handbook tell users to set up the /etc/zoneinfo file, and then run `emerge --config sys-libs/timezone-data`. That way, the actual /etc/localtime is set up in exactly the same way as when the TZ data are upgraded, and user types that information exactly once. Seems like a win-win to me. BTW, for some discussion about how the other distros tackle this, see [2]. [1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-libs/timezone-data/timezone-data-2013h.ebuild?revision=1.1&view=markup [2] https://git.reviewboard.kde.org/r/114321/
(In reply to Jan Kundrát from comment #8) > Sven, I'm afraid that your change is not correct. The /etc/timezone is read > by the pkg_config function within sys-libs/timezone-data (see [1]), and it > is important that it is set up properly. So indeed it's more complicated than the handbook suggested. It might be a good idea to instead advise the users to (1) write /etc/timezone and (2) run the same tool that is being run automatically on update (if I understand that correctly). > In short, there are two conflicting requirements: > > a) Update /etc/localtime whenever the underlying TZ file changes, i.e. on > update of the timezone-data package. This *can* be accomplished by a simple > symlink. Or /etc/timezone plus some automation, if I understand correctly. > b) Make it possible to function with /usr on a separate partition. Recently I recieved a message through 'eselect news' that a separate /usr is no longer supported. Does it mean we are ready to switch back to a simple symlink? > This > means that if /etc/localtime was a symlink to /usr, then stuff started prior > to /usr being available would get wrong TZ data. So, is this use case still considered valid or not? > Maybe the best would be to have the handbook tell users to set up the > /etc/zoneinfo file, and then run `emerge --config sys-libs/timezone-data`. That actually sounds much better than the current version at least if /etc/zoneinfo is still used. Depends on the answer to the question above. Or it might be actually good to have eselect for timezone so that we just need to modify the eselect and not the handbook in the future. Btw... http://packages.gentoo.org/package/app-admin/eselect-timezone > That way, the actual /etc/localtime is set up in exactly the same way as > when the TZ data are upgraded, and user types that information exactly once. > Seems like a win-win to me. +1 from me if we don't switch back to symlinks.
Ok, updated the paragraph on timezone file. I don't agree with the symlink; we had enough issues in the past with it. Also, the pkg_config() method also points out to users that, if they use symbolic links, then they're on their own. Also, I don't think we need to use --config timezone-data in the handbook there. We need to have a copy in /etc/localtime in place anyway first, otherwise pkg_config() returns 0 and does nothing.
(In reply to Sven Vermeulen from comment #10) > Also, I don't think we need to use --config timezone-data in the handbook > there. We need to have a copy in /etc/localtime in place anyway first, > otherwise pkg_config() returns 0 and does nothing. Wrong, the code in the ebuild does the right thing even when /etc/localtime is missing: svist ~ # cat /etc/timezone Europe/Prague svist ~ # rm /etc/localtime svist ~ # emerge --config sys-libs/timezone-data Configuring pkg... * Updating /etc/localtime with /usr/share/zoneinfo/Europe/Prague Changing the instructions to `$EDITOR /etc/timezone ; emerge --config sys-libs/timezone-data` has the benefit of requiring the user to enter the actual timezone info just once.
(In reply to Sven Vermeulen from comment #10) > Ok, updated the paragraph on timezone file. > > I don't agree with the symlink; we had enough issues in the past with it. That's not very specific. If the issues were all about separate /usr support, I guess they're obsolete now that separate /usr has been oficially abandoned in Gentoo. Also I guess (at least some) users are used to using symlinks for that and it would be useful if the handbook told them why they shouldn't do that. Sorry for the nitpicking, it's just that we already started the discussion. (In reply to Jan Kundrát from comment #11) > (In reply to Sven Vermeulen from comment #10) > > Also, I don't think we need to use --config timezone-data in the handbook > > there. We need to have a copy in /etc/localtime in place anyway first, > > otherwise pkg_config() returns 0 and does nothing. > > Wrong, the code in the ebuild does the right thing even when /etc/localtime > is missing: > > svist ~ # cat /etc/timezone > > Europe/Prague > > svist ~ # rm /etc/localtime > > svist ~ # emerge --config sys-libs/timezone-data Great. > Changing the instructions to `$EDITOR /etc/timezone ; emerge --config > sys-libs/timezone-data` has the benefit of requiring the user to enter the > actual timezone info just once. +1 Less duplication, lower risc of inconsistency and consequent surprises.
Discussion on whether /etc/localtime shall be a symlink belongs to the gentoo-dev ML, not to a bugreport against the docs.
There ya go, emerge --config is now used. Indeed, for symlink, best to use the gentoo-dev mailinglist. After all, we still support separate /usr - we just want the user to use an initramfs in that case.
(In reply to Sven Vermeulen from comment #14) > There ya go, emerge --config is now used. > > Indeed, for symlink, best to use the gentoo-dev mailinglist. After all, we > still support separate /usr - we just want the user to use an initramfs in > that case. It just means there's no window between switching to the real root and mounting the /usr. By the way, is there any manual about which request are allowed in the bugzilla and which need to be posted to the ML? I usually tend to prefer bugzilla for better tracking but it looks like you gentoo devs suggest that for this specific issue it's somewhat inappropriate.
There's no manual on that. Mostly it is because something is not a bug, but an opinion, and as such requires a wider audience to look at it and see if it is indeed beneficial to change it. For instance, for copying versus linking /etc/localtime, the end result is the same for end users. Copying doesn't introduce errors (and perhaps linking doesn't either - can't say for sure) so requesting to change this is equally similar as asking to switch from linking to copying.
