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

From: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Trond Eivind Glomsrød <teg(at)redhat(dot)com>, The Hermit Hacker <scrappy(at)hub(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)
Date: 2000-10-27 03:48:56
Message-ID: 39F8FB28.1CEA5591@wgcr.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers pgsql-ports

[Taken off GENERAL, added HACKERS to cc:]

Bruce Momjian wrote:
> > He's meaning the libpq version for dynamic link loading. Is the
> > libpq.so lib changing versions (like the change from 6.5.x to 7.0.x
> > changed from libpq.so.2.0 to libpq.so.2.1, which broke binary RPM
> > compatibility for other RPM's linked against libpq.so.2.0, which failed
> > when libpq.so.2.1 came on the scene). I think the answer is no, but I
> > haven't checked the details yet.

> I usually up the .so version numbers before entering beta. That way,
> they get marked as newer than older versions.

May I ask: is it necessary? Have there been version-bumping changes to
libpq since 7.0.x? (With the rate that necessary improvement is
happening to PostgreSQL, probably).

Let me explain:
RPM's contain a plethora of dependency information, some of which is
added manually, but most of which is generated automatically. These
dependencies are based on which 'soname' is needed to satisfy dynamic
linking requirements, interpreter requirements, etc. With version
numbers as part of the name, a change in version numbers changes the
dependency.
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)).

Now, that doesn't directly effect the PostgreSQL RPM's. What it does
effect is the guy who wants to install PHP from with PostgreSQL support
enabled and cannot because of a failed dependency. Who gets blamed?
PostgreSQL.

Trond may correct me on this, but I don't know of a workaround for
this. And any workaround has to be applied to packages that depend upon
PostgreSQL, not to the PostgreSQL RPM's (which I would gladly modify) --
although I am going to try something -- I know that a symlink to the old
soname works, even though it is a kludge and, IMO, stinks like a
polecat.

But, enough rant. That _is_ I believe what Trond was asking about. We
have been bitten before with people installing the PHP from RedHat 6.2
after installing the PostgreSQL 7.0.x RPMset -- and dependency failures
wreaked havoc.

So, PostgreSQL 7.1 is slated to be libpq.so.2.2, then?

Actually, Bruce, it would do me and Trond a great favor if a list of
what so's are getting bumped and to what version were to be posted. At
least we can plan for a transition at that point.

I just hate to pull a threepeat on RedHat customers. (RH 5.0 shipped PG
6.2.1. RH 5.1 shipped PG 6.3.2. BONG!) (RH 6.0 shipped 6.4.2 (bong!) RH
6.1 shipped 6.5.2 (double BONG!)). RH 7 shipped 7.0.x (small bong) --
RH 7.1 ships 7.1.x (ouch bong).

Whew. Trond, you ready for this?

[Note: I have been ill, so this message may be more incoherent than my
normal scattered self]
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Igor Roboul 2000-10-27 04:23:42 functions which return tuples
Previous Message Bruce Momjian 2000-10-27 03:11:34 Re: 7.0 vs. 7.1 (was: latest version?)

Browse pgsql-hackers by date

  From Date Subject
Next Message Hiroshi Inoue 2000-10-27 03:59:02 Re: pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c)
Previous Message Tom Lane 2000-10-27 03:36:19 Re: pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c)

Browse pgsql-ports by date

  From Date Subject
Next Message Bruce Momjian 2000-10-27 04:55:17 Re: 7.0 vs. 7.1 (was: latest version?)
Previous Message Bruce Momjian 2000-10-27 03:11:34 Re: 7.0 vs. 7.1 (was: latest version?)