Lamar Owen <lamar.owen@wgcr.org> writes:
> My gut feel is that RedHat may be better off shipping 7.0.x if the
> library version numbers are a contributory problem.
We could provide compat-packages with just neeeded libraries.
> The data upgrade problem is a bigger problem. To which RedHat might
> just want to stay at 7.0.x until either a tool is written to
> painlessly migrate or until the next major RedHat is released.
We upgrade everything from 3.0.3 (we no longer support upgrades from
2.0 as we couldn't find a specific way to identify such a system and
we didn't want accidentaly upgrade other distributions), so there is
pain anyway.
> Of course, that doesn't affect what I do as far as building 7.1 RPM's
> for distribution from the PostgreSQL site (or by anyone who so desires
> to distribute them). I have no choice for my own self but to stay on
> the curve. I need TOAST and OUTER JOINS too much.
Others very likely have the same need. I'll be looking into issues
with these later.
> So, what I feel may be the best compromise is for RedHat (and myself) to
> continue building 7.0.x RPM's with bugfixes, etc, while I build 7.1 ad
> subsequent RPMset's for those who know what they're doing and not
> blindly upgrading their systems.
> Trond, do you have any comments on that? Or is the likely migration to
> kernel 2.4 in the next RedHat going to make a compatability compromise
> here moot?
No, the 2.4 kernel should go right in - I've been using it extensively
on my system until recently (the most recent pretest has problems with
flock for sendmail).
Anyway, I've had a look at psql in objdump:
Dynamic Section: NEEDED libpq.so.2.1 NEEDED libcrypt.so.1 NEEDED libnsl.so.1 NEEDED libdl.so.2
NEEDED libm.so.6 NEEDED libutil.so.1 NEEDED libreadline.so.4.1 NEEDED libtermcap.so.2 NEEDED
libncurses.so.5NEEDED libc.so.6
[...]
It links against nice, round versions of most libraries but wants
specific versions of readline ad libpq.
--
Trond Eivind Glomsrød
Red Hat, Inc.