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: Tue, 22 May 2012 01:10:41 +0900

Sukneet Basuta (sukneet AT gmail.com) wrote [12.05.21 22:47]:
> 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 .

Presumably the original discussion was about only using ln -s, which
means if we do it manually there's no hardlinking, only symlinking. If
the exact same functionality was manually coded in the spell (harlink if
able, otherwise symlink) then it doesn't make sense to do it manually.

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

This is a matter of point-of-view/preference and policy. What I was
stating I made quite clear was my own preference, and I have no idea how
many share it. I may be alone, or I may be in the majority. I have no
idea. It seems only Arjan and I are responding to this thread though, so
I doubt you'll get a consensus unless more people start chiming in.

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

All of this implies that we should retain the option for now, at least
until we can guarantee that everything works as it should.

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

I'm not. Upstream is. I'm simply suggesting we follow upstream. That
being said, for any major change, especially with critical components
like libc, you should always provide a transition period for users
because there are always problems that crop up (like the current
issues), and not everyone runs bleeding edge. Since you can't expect
everyone to have already updated by the time you've worked out the bugs
on your own system, you let users transition up to the newer version, to
avoid major gotchas. This is why upstream is deprecating the inbuilt
tzdata but still offers it.

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

The new chroot being...? And a non-fresh install being...? These are a
bit vague.

Of particular interest are the versions of glibc before updating to the
new version for testing, and what options were enabled. It seems though
from Arjan and you that there aren't really any major issues aside from
the /etc/localtime issue.

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

Attachment: pgpv3c49q21AN.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page