LFS Wiki UserNotes

Barius Drubeck barius.drubeck at gmail.com
Sat Feb 3 12:22:50 PST 2007

On Saturday 03 February 2007 07:19, Dan Nicholson wrote:
> On 2/2/07, Barius Drubeck <barius.drubeck at gmail.com> wrote:
> > On the other hand, it is indeed a problem specific to supporting
> > and maintaining ancient systems with ancient glibc, thus
> > temporaly far *beyond* LFS, and therefore has little to do with a
> > fresh LFS build of a new system.
> Actually, this isn't a problem specific to supporting ancient
> glibcs. In this particular case, we're talking about timezone data
> that was updated between glibc-2.3.2 and glibc-2.3.6, but the
> timezone data can be updated at any time. If there's an update to
> the timezone data now, is my glibc-2.3.6 considered ancient? Even
> if you have glibc-2.5, it doesn't mean you have the most current
> timezone data.

Sorry, I overstated that a bit.

What I meant is that timezone data changes tend to be announced well 
in advance, and thus tend to get integrated into glibc long before 
the change becomes effective.  Certainly, there are no guarantees 
that this will be the case.  Maybe it's even just wishful 

And no, I don't consider glibc-2.3.6 ancient.  Like I said, I 
overstated.  (Although 2.4 has been around for almost a year.)
But admit, your 2.3.6 does contain the tz update as per my wishful 
thinking above ;-)

Thinking practically, what are the odds of more than one major tz 
change during the lifetime of an LFS book version?  And how portable 
is the tz update procedure from one book version to another?  IMHO, 
those two questions ought to be considered in choosing the optimal 
format and placement of the procedure.


More information about the lfs-dev mailing list