On Saturday 03 February 2007 07:19, Dan Nicholson wrote: > On 2/2/07, Barius Drubeck <[EMAIL PROTECTED]> 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 thinking.... 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. -- Barius -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
