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 16:37:05 +0900

Sukneet Basuta (sukneet AT gmail.com) wrote [12.05.21 15:20]:
> I'm aware of the differences. Given that zic creates a symlink if it
> cannot create a hardlink, in the case of a separate /usr partitions, I
> don't see how the result is any different than manually creating a
> symlink.

1) Hardlinks require the target to exist at creation time, while symlinks
do not (as I pointed out), but this additionally means the targets to be
on the same "device" (which here means partition). Thus zic will always
produce symlinks when the link is to be on a separate partition than the
original file.

2) Symlinks are "heavier" than hardlinks (disk usage, access speed,
etc.).

3) Hardlinks "look" like normal files (eg ls -l), whereas symlinks
always appear as links. Additionally, if you remove the file a hardlink
points to and then operate on the hardlink, you do not get an error
about a missing file, whereas if it's a symlink, it will error out that
there is no such file.

Manually creating a symlink results in a difference when the files are
on the same partition, compared to hardlinking them. There are pros and
cons for both (2 vs. 3). It may be that the SA would prefer a symlink
even when the files are on the same device, or maybe the SA always
prefers hardlinks when available. IMHO it should be up to the SA.

> > Copying/installing will result in an override of whatever is stored in
> > /usr, since it will just use the actual file in /etc.
>
> Is that an issue? Assuming that tzdata installs the file, it will be
> updated whenever the files in /usr/zoneinfo change.

It's an issue if the SA had or wants a link instead of a raw file (disk
usage, organization), or if the SA modifies the file. It's less of an
"issue" for modification, since that would be resolved via confmeld, but
it's still a difference to be aware of and thought about (since an error
in the install/confmeld would possibly trash their custom file -- but we
can pray that sorcery is perfect and will never have such an error :-D).

> > 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.
>
> I thought it was a good idea. If you guys feel differently, remove it.
> Thinking about it now though, if a user wants to use a custom timezone
> file, that will be an issue. I'll make it an option.

I have no idea how anyone else feels about managing timezones. That was
just my own preference, as I stated. ;)

However, there are two points to consider here. One is the differences
between hardlink, symlink, and regular file as discussed above. The
other (which is often ignored across the board) is a "security" issue:
locked down systems may have a read-only /etc, and the SA may expect a
glibc install to need access to changing files in /usr, but not
necessarily in /etc, so if the SA doesn't first remount /etc read-write
the install will fail. I kind of doubt we have anyone using SMGL who
isn't already used to dealing with this problem regularly though, as we
have tons of spells that don't worry about this anyway.

> > 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.
>
> The version in glibc is fairly outdated and is just an older version
> of tzdata. We will have to provide this eventually (assuming we don't
> stick with glibc 2.13 forever) since upstream has chosen not to
> install timezone rule files.
> If we do supply an option it would have to be in glibc.

But is the timezone data currently packaged within glibc itself? That's
my current understanding. If upstream removes it later, then we can also
remove it later. I was just wondering what was the reasoning for
removing it as an option now. We could allow for a transition period,
just like upstream is (assuming that the tzdata is, in fact, currently
bundled).

> On a semi-related note, is there any reason why we haven't updated to
> glibc 2.14 with a patch to re-enable sunrpc? I ran that for quite a
> while without any issues. I have since updated to 2.15, but that
> introduces a number of problems.

I don't personally know of the issues, but I seem to remember some
people having various problems, not only sunrpc. I may be wrong, as this
is purely off my clearly unreliable memory. :)

> > Commit: Arjan Bouter <abouter AT sourcemage.org>
> >
> > tzdata: use ln instead of zic so the spell works if /etc and /usr are
> > on
> > different partitions. Note that the SA still has to clean
> > /usr/share/zoneinfo or the spell will fail.
>
> Does anyone else have to remove /usr/share/zoneinfo for tzdata to
> INSTALL correctly? My tests showed this was only an issue when Arjan's
> test basesystem tar was used.
> If so, I'll make the spell remove the relevant files under
> /usr/share/zoneinfo.

I haven't tested it yet, and probably won't have a chance to for a while
yet. I'm rather buried in RL dealings. I'll just ask though: have you
tested from other fresh basesystems/installs that don't have the new
zoneinfo already available? We should ensure a smooth and stable upgrade
path.

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

Attachment: pgpCfvr3axMHL.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page