Re: Getting to 8.3 beta1 - Mailing list pgsql-hackers

* Gregory Stark (stark@enterprisedb.com) wrote:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
> > Stephen Frost <sfrost@snowman.net> writes:
> >> Bumping the soname is an indication of a binary-incompatible change and
> >> means that old binaries *can't* link against the new library, and so
> >> everything has to be recompiled.  Please don't do that unless it really
> >> is a binary-incompatible change because it's alot of extra work for
> >> packagers to deal with all of their reverse dependencies and getting
> >> everyone to recompile.
> >
> > It's not only a question of whether old binaries can use the newer
> > library; it's a question of whether a package's dependencies correctly
> > show that it needs the newer library (if it does).  Without this,
> > dependency-solving update systems like yum, apt, etc may fail to install
> > prerequisite updates.
>
> Well either way would work for apt. It notices the version of the library
> installed when you build a package and records that version as the dependency
> of the package.

More specifically, it records the "shlibs" of the library into the
dependency of the package being built.  That is *not* the same as the
exact version of the particular library being being against.  The
"shlibs" shouldn't ever be *higher* than the version of the library, but
it can, and often is, *lower*.

> If you don't bump then it means you can only have one version of libpq
> installed at the same time. When installing the new libpq from the 8.3
> packages all existing packages would immediately start using it. Any packages
> built while the new library was installed would claim to depend on the new
> version (unless the packager overrode the automatic shlib dependency).

Right, assuming that we're talking about a case where there was some
backward-compatible change in the ABI (functions were added), as in this
case.

> If you do bump then it means you can keep both copies of the library
> installed. All old packages would continue to use the old library until
> they're rebuilt. If they're rebuilt when the new package is installed then
> they'll start depending on the new version.

This really is rather ugly when you have to deal with it though.  It
means that packages *have* to be rebuilt to use the new library and
it makes it a huge pain to get rid of the old library.  It also puts you
in the ugly and annoying situation that both libraries can end up linked
into the same running binary.

> I'm not sure how yum works, does it not handle this case?

Yeah, I'm not familiar with non-Debian systems, though the major/minor
approach to libraries is used on most systems I've had occation to work
with.  Though, honestly, on the commercial (Sun, Irix, HPUX, etc)
systems I've run into, the admins tend to ignore the whole issue
entirely and just recompile/upgrade everything anyway.  It's been a
while tho, so perhaps things have changed.

> Separately are we really sure the shared libraries are completely binary
> compatible? Didn't the password authentication do something tricky? If you
> have existing binaries there's no case where they'll break if you swap the
> shared library out from under them?

This is where I was suggesting doing something like running the
regression tests using old client libraries linked against the new
library.  If there's a binary-incompatible change then the path is
clear.  If the regression tests work fine then I'd feel comfortable
just bumping the minor version and leaving the real 'soname' alone.
Thanks,
    Stephen