Re: 8.02 rpm error

On Friday 20 May 2005 09:43, Dave Cramer wrote:
> Lamar Owen wrote:
> >On Friday 20 May 2005 07:55, Dave Cramer wrote:
> >>Well, there's not much discussion here. Other than the fact that a few
> >>things depend on libpq.so.3.
> >>Isn't the standard to keep libpq.so.(n-1) whenever you bump the number up
> >> ?

> >Only because libpq versioning has always been an afterthought in the
> > upstream release process.

> OK, so how do we fix this ?

Any time a change is made to libpq that changes its exported symbols or ABI a
version change needs to be made. The person committing the change that
impacts the ABI needs to be the person responsible for changing the version
number; otherwise someone needs to monitor libpq changes coming down
committers and remind people when they need to bump the libpq major or minor
so version. Further, any time a release is being built one of the top things
on the checklist should be 'is libpq's soname appropriate or not?'

Changing past releases is impossible and must be worked around, which is quite
honestly ugly to do. The cleanest thing, yet painful as it is, is to simply
not provide the .3 at all and people will just have to rebuild all their
clients. This gives a clean break; no, we can't fix 8.0.0, but we can fix
from this point forward. People will complain, loudly, when it's broken; but
which is better? Forcing a clean break with one-time pain, or having pain
every single 8.0.x release? This situation should really drive home the
importance of being careful!

Basically it boils down to being more careful when piping out a release.
PostgreSQL is no longer an island where we depend on OS services and few
people depend on us; rather, libpq in particular is becoming a core component
of distributions all around, and thus libpq must be very carefully maintained
as a result; we have to, pardon the pun, watch our p-q's. Too many other
projects are depending upon the soname in libpq to indicate the exported
interface. And, where exported interfaces vary according to compile-time
options, we need to change the soname based on the options (such as SSL
versus non-SSL builds). And we must be consistent in the versioning; people
tend to expect minor version upgrades to not break things, and 8.0.1 broke
things. The discussion on why the version was bumped this time is in the
archives; people are now fighting a battle with that decision. The decision
to bump the version of libpq was the correct one to make; it just should have
been made before 8.0 was released and not after. But all this discussion is
in the archives; I would suggest browsing those threads.

The fftw3 library provides a reasonable model with which to work; there are
multiple compile-time options there that dramatically change the ABI (things
like integer versus single-precision float versus double-precision float),
and the route the fftw3 developers have taken is to make separate names for
each. This way OS linking and dependency resolution isn't broken arbitrarily
because otherwise there is no way of communicating to the linkloader which
ABI we're exporting today.

And I've made enough release piping errors to recognize one.... :-)
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu