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: Sukneet Basuta <sukneet AT gmail.com>
  • 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 09:47:25 -0400

On Mon, May 21, 2012 at 3:37 AM, flux <flux AT sourcemage.org> wrote:
> 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.

Right, but I'm asking what is the difference between zic creating a
symlink and us creating a symlink with ln -sf. zic uses libc's
symlink() to create the symlink which I assume provides the same
result as ln -s .

If the option to not install a local timezone is provided, do you
think it's safe to assume that the SA accepts our selected method to
link /etc/localtime?

>> > 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).

Yes it is. It is even still there in their git repo. AFAIK, they are
simply providing a copy of tzcode.

There is no technical reason for this. I am doing a new install on my
laptop to test the upgrade path from test to devel-xorg (using Arjan's
basesystem, since I started this just before the new chroot was
released - I'm moving along slowly), so I'm addressing any issues I
encounter along the way. Originally, I patched my version of glibc
because I was using Arjan's basesystem tar, which has that
/usr/share/zoneinfo issue (glibc would fail to install when I updated
it, leaving me with a very broken system). I still needed the timezone
files, so I looked at what Archlinux and Fedora did. They supplied the
files with tzdata, so I created a spell for it. I thought this was a
much wider issue until I tested out the new chroot, but I had already
did the work.

Basically, I pushed this simply because it will need to be done
eventually and I already did it, and (other than this /etc/localtime
issue) I don't see any disadvantages to this. You get an updated
timezone database (providing bugfixes/updates for SAs) and glibc does
not fail to install in the case Arjan's basesystem was used.

Coincidentally, Bug 6959 (
http://sourceware.org/bugzilla/show_bug.cgi?id=6959 ) is cited in the
changelog, so Source Mage could very well be the reason for upstream's
change ;) (I'm sure there is a much better reason for their change)

What are your reasons for wanting/needing a transition period? tzdata
just supplies you with an updated version of the same rules, so I'm
not sure why it would be needed.

>> 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. :)

Anyone know what the issues were? I'm sure there are patches for them
somewhere.
The revert message in git, states that the rpc issue was the reason
for the revert.

>> > 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.

Yes I have tested it on the new chroot and on an non-fresh install
from the iso. I only had issues with Arjan's basesystem, which has the
same issue with glibc anyway. If you manually remove
/usr/share/zoneinfo once, the issue seems to go away.

On Mon, May 21, 2012 at 8:10 AM, Arjan Bouter <abouter AT sourcemage.org> wrote:
> I'm just thinking out loud here, but if glibc's zoneinfo is just an old
> tzdata
> version, then why not replace it in glibc's PRE_BUILD?
> That way we don't even need a separate tzdata spell.
>
> Or am I missing something here?

Because tzdata updates independently from glibc.




Archive powered by MHonArc 2.6.24.

Top of Page