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: Arjan Bouter <abouter AT sourcemage.org>
  • To: flux <flux AT sourcemage.org>
  • Cc: sm-commit AT lists.ibiblio.org
  • Subject: Re: [SM-Commit] GIT changes to master grimoire by Arjan Bouter (799113ffd65dbd5d6c41bc47925d9db3e101ffda)
  • Date: Mon, 21 May 2012 18:34:03 +0200

On Tue, 22 May 2012 01:10:41 +0900
flux <flux AT sourcemage.org> wrote:

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

the spell used zic, which threw me an error about the target being on a
separate
filesystem. That made the spell fail.
Using ln in the spell makes it work regardless of the partition layout.
To me that sounds like a really simple choice ;)

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

As long as we have a choice as what timezone to select I don't really mind the
spell setting /etc/localtime.

>
> > 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 funny thing about the basesystem tarball I made is that I just extracted
the previous tarball, chrooted into it, updated it, cleaned up and re-packed
it.
At no point did I use anything from my own box for the updated tarball.

And yet my own box which has been running for years on the same smgl install
threw the exact same error as the basesystem tarball does.


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

if we keep the spell as it is now, we need to make it remove the leftover
zoneinfo from glibc. I had to manually remove it before I could cast tzdata.
Not being able to do unattended updates is annoying at least.

What about dropping the tzdata spell and updating the glibc spell to use the
tzdata-data instead of the outdated info? That would solve all the issues if
we add a couple of queries about if and how the spell sets /etc/localtime.

Arjan Bouter

+===================
Source Mage GNU/Linux developer,
http://www.sourcemage.org
+============




Archive powered by MHonArc 2.6.24.

Top of Page