LFS Wiki UserNotes
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