Re: Redhat 7.3 time manipulation bug

From: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
To: Ulrich Drepper <drepper(at)redhat(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Michael Meskes <meskes(at)postgresql(dot)org>, PostgreSQL Hackers List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Redhat 7.3 time manipulation bug
Date: 2002-05-28 02:18:17
Message-ID: 200205272218.17200.lamar.owen@wgcr.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Friday 24 May 2002 03:15 pm, Ulrich Drepper wrote:
> This is getting silly.

Yes, Ulrich, it is. Very silly. And Red Hat's stance is one of the silliest,
IMHO.

>You'll see that the glibc in RHL7.3 contains a lot of the
> code from the glibc 2.3 branch. It's not named 2.2.90 because major
> pieces are missing.

> If you still don't know that version numbers are meaningless for
> determining feature lists you might want to consider going back to your
> CS101 class and revisit software configuration management.

IOW, Red Hat's glibc 2.2.5 isn't really pristine glibc 2.2.5 as found straight
from the GNU repository. In fact, Red Hat glibc 2.2.5 isn't really 2.2.5 --
how about 2.2.96? :-) .96 was good enough for gcc....

Furthermore, Red Hat glibc 2.2.5 isn't even fully compatible with GNU glibc
2.2.5 -- at least in the area of time_t stuff.

In the open source world, version numbers are actually supposed to mean
something -- at least for package dependencies. Of course, I also have read
the kernel-2.4.18 source RPM and its 21.8MB 'ac-bits' patch.

You do realize that this sort of thing doesn't help Red Hat's PR state amongst
the greater open source community, right? Nor would it help Mandrake, SuSE,
or any other Linux distributor (I specifically excluded Debian due to its
unique community supported state). But, if you don't care about the greater
open source community, well...

And I say all of that while running and enjoying the greater part of Red Hat
7.3. For the most part it is extraordinarily stable. And I know that that
21.8MB kernel patch is one of the reasons it is so stable. But I still
question the versioning of glibc.

So, in summary, the glibc version number in any particular linux distribution
is meaningless because the distributor is free to patch the bloody daylights
out of it at any time. Sweet. And so standard.

But, if glibc 2.3 is where this bit came from, it is just a matter of time
before all Linux distributions (that aren't willing to patch away) get this
braindead behavior. Oh well. The general solution will happen.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2002-05-28 03:54:14 Re: SRF rescan testing
Previous Message Neil Conway 2002-05-28 01:17:31 Re: [HACKERS] Re : Solaris Performance - 64 bit puzzle