Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?) - Mailing list pgsql-hackers
From | Lamar Owen |
---|---|
Subject | Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?) |
Date | |
Msg-id | 39F8FB28.1CEA5591@wgcr.org Whole thread Raw |
Responses |
Re: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)
|
List | 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 by date: