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

From: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Trond Eivind =?iso-8859-1?Q?Glomsr=F8d?=" <teg(at)redhat(dot)com>, The Hermit Hacker <scrappy(at)hub(dot)org>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)
Date: 2000-10-27 19:30:34
Message-ID: 39F9D7DA.D81A5A74@wgcr.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers pgsql-ports

Tom Lane wrote:
>
> Lamar Owen <lamar(dot)owen(at)wgcr(dot)org> writes:
> > Unfortunately RPM deems a dependency upon libpq.so.2.0 to not be
> > fulfilled by libpq.so.2.1 (how _can_ it know? A client linked to 2.0
> > might fail if 2.1 were to be loaded under it (hypothetically)).
>
> If so, I claim RPM is broken.
>
> The whole point of major/minor version numbering for .so's is that
> a minor version bump is supposed to be binary-upward-compatible.
> If the RPM stuff has arbitrarily decided that it won't honor that
> definition, why do we bother with multiple numbers at all?
>
> > So, PostgreSQL 7.1 is slated to be libpq.so.2.2, then?
>
> To answer your question, there are no pending changes in libpq that
> would mandate a major version bump (ie, nothing binary-incompatible,
> AFAIK). We could ship it with the exact same version number, but then
> how are people to tell whether they have a 7.0 or 7.1 libpq?

And that is a very good point. Hey, I'm caught in the middle here :-).
I want to see PostgreSQL succeed and excel (which, to me, means becoming
the RDBMS of choice) on RPM-based Linux distributions, which I am sure
is a goal of others too. And I'm sure no one here is against that.

But, there is friction between RedHat's (to use the first example of a
distributor to pop into my head) needs and the needs of the PostgreSQL
group.

My gut feel is that RedHat may be better off shipping 7.0.x if the
library version numbers are a contributory problem. 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.

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.

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?
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Trond Eivind =?iso-8859-1?q?Glomsr=F8d?= 2000-10-27 19:42:15 Re: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)
Previous Message Bruce Momjian 2000-10-27 19:21:38 Re: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)

Browse pgsql-hackers by date

  From Date Subject
Next Message Trond Eivind =?iso-8859-1?q?Glomsr=F8d?= 2000-10-27 19:42:15 Re: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)
Previous Message Tom Lane 2000-10-27 19:25:37 Re: Summary: what to do about INET/CIDR

Browse pgsql-ports by date

  From Date Subject
Next Message Trond Eivind =?iso-8859-1?q?Glomsr=F8d?= 2000-10-27 19:42:15 Re: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)
Previous Message Bruce Momjian 2000-10-27 19:21:38 Re: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)