Re: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)

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.