Skip to Content.
Sympa Menu

sm-commit - Re: [SM-Commit] GIT changes to master grimoire by Arjan Bouter (799113ffd65dbd5d6c41bc47925d9db3e101ffda)

sm-commit AT lists.ibiblio.org

Subject: Source Mage code commit list

List archive

Chronological Thread  
  • From: flux <flux AT sourcemage.org>
  • To: sm-commit AT lists.ibiblio.org
  • Subject: Re: [SM-Commit] GIT changes to master grimoire by Arjan Bouter (799113ffd65dbd5d6c41bc47925d9db3e101ffda)
  • Date: Mon, 21 May 2012 12:59:51 +0900

Sukneet Basuta (sukneet AT gmail.com) wrote [12.05.21 12:14]:
> > Are you sure that is the case? I actually looked into this before I
> > did it and I read the opposite. If /usr and /etc are on different
> > partitions and /usr fails to mount, /etc/localtime will fail, but not
> > if zic installs it. When zic installs it, it makes a copy to
> > /etc/localtime rather than a link, so I don't see how or why it should
> > fail. Based on what I read zic is more robust than straight linking. I
> > don't have a separate /usr partition though so I couldn't do much
> > testing.
>
> Actually, I just looked at the code for zic and it actually tries to
> create a hard link first, then if that fails it creates a symlink. So
> I guess either way is pretty much equivalent. Using install or cp
> maybe a better solution though. I'll leave it up to you to decide.

Hardlinking and symlinking are not equivalent. Also, cp/install is not
equivalent to either form of linking. They all do different things.

If you have /usr mounted on a separate partition, hardlinking will fail
since the file is required to actually be present. Symlinking doesn't
need a file at link creation time, only at access time (hardlinking
still needs the file at access time as well).

Copying/installing will result in an override of whatever is stored in
/usr, since it will just use the actual file in /etc.

Whatever method is used, there are pros and cons. Personally I think it
should be the SA's responsibility to manage /etc/localtime. Don't touch
it at all, and instead provide some info about it and the related issues
in a message in FINAL. This is my own preference, however.

Is it perhaps better to leave glibc using the older and inbuilt
timezones, with an _option_ to use the newer (and separate) timezone
data? Or the other way around? I don't see why the newer timezone
package needs to be forced on users.

--
Justin "flux_control" Boffemmyer
Cauldron wizard and general mage
Source Mage GNU/Linux
http://www.sourcemage.org

Attachment: pgpWk63Ik_rFK.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page