Matthias Andree matthias.and...@gmx.de wrote:
If they're in the same physical FS there's no need for a symlink.
You might as well use a hardlink.
And then discuss how all the time zone configuration tools deal
with /etc/localtime - truncate/overwrite, direct overwrite ...
In that case
Matthias Andree matthias.and...@gmx.de wrote:
Am 28.03.2011 19:57, schrieb dieter...@engineer.com:
I have been running FreeBSD and NetBSD with /etc/localtime being
a symlink for years and have not seen any problems as a result.
In that case, /etc and /usr/share/timezone (or whatever) need
Am 29.03.2011 09:53, schrieb per...@pluto.rain.com:
Matthias Andree matthias.and...@gmx.de wrote:
Am 28.03.2011 19:57, schrieb dieter...@engineer.com:
I have been running FreeBSD and NetBSD with /etc/localtime being
a symlink for years and have not seen any problems as a result.
In that
On Sun, Mar 27, 2011 at 09:38:29PM -0400, Ed Maste wrote:
On Sun, Mar 27, 2011 at 03:27:32PM -0700, David Wolfskill wrote:
There are other ways to do it, of course -- e.g., the first time the
utility is run, it could actually ask, but then cache the information in
some place so it could
And while I (think I) recall that the equivalent of /etc/localtime
was implemented in some version of SunOS many years ago as a symlink,
I believe that approach could be problematic for FreeBSD, as it
could impose some unintended requirements on some of the start-up
scripts.
I have been
On Mon, Mar 28, 2011 at 10:57 AM, dieter...@engineer.com wrote:
And while I (think I) recall that the equivalent of /etc/localtime
was implemented in some version of SunOS many years ago as a symlink,
I believe that approach could be problematic for FreeBSD, as it
could impose some unintended
Sent from my iPad
On Mar 28, 2011, at 10:57 AM, dieter...@engineer.com wrote:
And while I (think I) recall that the equivalent of /etc/localtime
was implemented in some version of SunOS many years ago as a symlink,
I believe that approach could be problematic for FreeBSD, as it
could impose
On Mon, Mar 28, 2011 at 2:10 PM, Garrett Cooper gcoo...@freebsd.org wrote:
On Mon, Mar 28, 2011 at 10:57 AM, dieter...@engineer.com wrote:
And while I (think I) recall that the equivalent of /etc/localtime
was implemented in some version of SunOS many years ago as a symlink,
I believe that
2011/3/28 dieter...@engineer.com:
And while I (think I) recall that the equivalent of /etc/localtime
was implemented in some version of SunOS many years ago as a symlink,
I believe that approach could be problematic for FreeBSD, as it
could impose some unintended requirements on some of the
On Mon, Mar 28, 2011 at 11:10:42AM -0700, Garrett Cooper wrote:
On Mon, Mar 28, 2011 at 10:57 AM, dieter...@engineer.com wrote:
I have been running FreeBSD and NetBSD with /etc/localtime being
a symlink for years and have not seen any problems as a result.
+1. Many Linux distros do the
On Mon, Mar 28, 2011 at 02:22:01PM -0400, Maxim Khitrov thus spake:
Same here, though I'd be happy to change this habit if mergemaster
handled the updates for me.
This would be a good solution for source updates, but how would this work
for binary upgrades via freebsd-update, as mergemaster is
On Mon, 2011-03-28 at 11:48 -0700, Jason Helfman wrote:
On Mon, Mar 28, 2011 at 02:22:01PM -0400, Maxim Khitrov thus spake:
Same here, though I'd be happy to change this habit if mergemaster
handled the updates for me.
This would be a good solution for source updates, but how would this
Am 28.03.2011 19:57, schrieb dieter...@engineer.com:
And while I (think I) recall that the equivalent of /etc/localtime
was implemented in some version of SunOS many years ago as a symlink,
I believe that approach could be problematic for FreeBSD, as it
could impose some unintended
And while I (think I) recall that the equivalent of /etc/localtime
was implemented in some version of SunOS many years ago as a
symlink,
I believe that approach could be problematic for FreeBSD, as it
could impose some unintended requirements on some of the start-up
scripts.
I have been
On 03/27/2011 18:38, Ed Maste wrote:
That's what tzsetup does in HEAD - the name of the selected timezone file
is stored in /var/db/zoneinfo, and tzsetup -r can be used to copy in an
updated file:
-r Reinstall the zoneinfo file installed last time. The
name is obtained from
On Mon, 2011-03-28 at 16:52 -0400, dieter...@engineer.com wrote:
And while I (think I) recall that the equivalent of /etc/localtime
was implemented in some version of SunOS many years ago as a
symlink,
I believe that approach could be problematic for FreeBSD, as it
could impose some
2011/3/29 Devin Teske dte...@vicor.com:
On Mon, 2011-03-28 at 16:52 -0400, dieter...@engineer.com wrote:
And while I (think I) recall that the equivalent of /etc/localtime
was implemented in some version of SunOS many years ago as a
symlink,
I believe that approach could be problematic for
On Tue, 2011-03-29 at 00:51 +0200, Olivier Smedts wrote:
2011/3/29 Devin Teske dte...@vicor.com:
On Mon, 2011-03-28 at 16:52 -0400, dieter...@engineer.com wrote:
And while I (think I) recall that the equivalent of /etc/localtime
was implemented in some version of SunOS many years ago as
On 03/28/2011 16:22, Devin Teske wrote:
In which case, I can jump up and down for joy and tell my boss that it's
once-again kosher to set /etc/localtime as a symbolic link.
It has always been true that the only safe way to make /etc/localtime
a symlink is to have / and /usr on the same
: Doug Barton
To:Ed Maste
Cc:David Wolfskill , ,
Sent:Mon, 28 Mar 2011 14:11:42 -0700
Subject:Re: Keeping /etc/localtime up-to-date
On 03/27/2011 18:38, Ed Maste wrote:
That's what tzsetup does in HEAD - the name of the selected
timezone file
is stored in /var/db/zoneinfo, and tzsetup -r can
Recent changes to /usr/share/zoneinfo have reminded me that my
regular updates to my FreeBSD machines via source update
/usr/share/zoneinfo, but /etc/localtime remains a copy of whatever
was in /usr/share/zoneinfo for the selected zone at the time
tzsetup(8) was last run -- and I certainly don't
On 03/27/2011 08:38, David Wolfskill wrote:
It would (in principle) be possible to teach mergemaster(8) how to
do this (possibly by including a cookie in ~/.mergemasterrc or
/etc/mergemaster.rc to tell it what the reference zoneinfo pathname
is), but this type of approach seems sufficiently
On Sun, Mar 27, 2011 at 01:31:22PM -0700, Doug Barton wrote:
On 03/27/2011 08:38, David Wolfskill wrote:
It would (in principle) be possible to teach mergemaster(8) how to
do this (possibly by including a cookie in ~/.mergemasterrc or
/etc/mergemaster.rc to tell it what the reference zoneinfo
On Sun, Mar 27, 2011 at 03:27:32PM -0700, David Wolfskill wrote:
There are other ways to do it, of course -- e.g., the first time the
utility is run, it could actually ask, but then cache the information in
some place so it could look there first (and if it finds a cached
answer, avoid asking
On Mar 27, 2011, at 1:31 PM, Doug Barton wrote:
On 03/27/2011 08:38, David Wolfskill wrote:
So it seems to me that requirements would be:
* The content of /etc/localtime must provide the appropriate
zoneinfo information, even when/usr/share/zoneinfo/* has been
modified (or shortly
At Sun, 27 Mar 2011 13:31:22 -0700,
Doug Barton wrote:
This is more along the lines of something that would be easy to work
with in mergemaster. If I can tell what file in /usr/share/zoneinfo to
compare /etc/localtime to (ideally with fully path), I'm happy to
provide a mechanism in
26 matches
Mail list logo
