[ Blind CC to general added for comment below.]
> [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).
No, only major releases have bumps.
> 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.
See pgsql/src/tools/RELEASE_CHANGES. I edit interfaces/*/Makefile and
increase the minor number for every interface by one.
Let me add one thing on this RPM issue. There has been a lot of talk
recently about RPM's, and what they should do, and what they don't do,
and who should be blamed. Unfortunately, much of the discussion has
been very unproductive and more like 'venting'.
I really don't appreciate people 'venting' on these lists, especially
since we have _nothing_ to do with RPM's. All we do is make the
If people want to discuss RPM's on the ports list, or want to create a
new list just about RPM's, that's OK, but venting is bad, and venting on
a list that has nothing to do with RPM's is even worse.
What would be good is for someone to constructively make a posting about
the known problems, and come up with acceptible solutions. Asking us to
fix it really isn't going to help because we don't deal with RPM's here,
and we don't have enough free time to make significant changes to meet
the needs of RPM's.
Also, remember we support many Unix platforms, and Linux is only one of
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
In response to
pgsql-ports by date
|Next:||From: Tom Lane||Date: 2000-10-27 14:54:27|
|Subject: Re: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?) |
|Previous:||From: Lamar Owen||Date: 2000-10-27 03:48:56|
|Subject: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)|
pgsql-hackers by date
|Next:||From: Michael Teter||Date: 2000-10-27 05:01:41|
|Subject: renaming columns... danger?|
|Previous:||From: Tom Lane||Date: 2000-10-27 04:34:18|
|Subject: Re: pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c) |
pgsql-general by date
|Next:||From: Bruce Momjian||Date: 2000-10-27 04:57:10|
|Subject: Re: Issues about postgresql file names|
|Previous:||From: Jason Earl||Date: 2000-10-27 04:43:11|
|Subject: Re: binary data and TEXT|