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

Поиск
Список
Период
Сортировка
От Lamar Owen
Тема Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)
Дата
Msg-id 39F8FB28.1CEA5591@wgcr.org
обсуждение исходный текст
Ответы Re: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)
Список pgsql-hackers
[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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Larry Rosenman
Дата:
Сообщение: Re: Summary: what to do about INET/CIDR
Следующее
От: Ian Lance Taylor
Дата:
Сообщение: Re: Re: [GENERAL] A rare error