Re: Getting to 8.3 beta1

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> 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.

Right, the minor version bump tells the maintainer (and/or if he/she
follows the dev lists/release notes) to adjust the dependencies.  The
maintainer would then adjust, at least on Debian, the shlibs files when
building the new library and packages using dh_makeshlibs, dh_shlibdeps,
dpkg-shlibdeps, etc would pick up on the new dependency.

The new version of the library will be installed whenever it's scheduled
to be upgraded, or immediately if new binaries that have been compiled
against it are also being installed.

Technically, that's strictly harsher than it has to be, but if you're
recompiling you might as well require the latest ABI even if you don't
use the new functions.  Figuring out if the new functions are
being used or not so that you could perhaps allow for use of an older
library is probably more trouble than it's worth and would require much
more complicated dependencies that would buy very little...

> If we can skip the compatibility-package pushup this time around,
> I'll be as happy as anyone.  But I'm worried about getting into the
> kind of mess we had in 8.0, where we decided *after* release that
> we needed a soname bump :-(

I agree, that's certainly quite ugly, but if we've only added functions
and not changed existing function ABIs at all then I can't see any
reason why that would happen here.  We're quite confident there have
been only new funcs, right?  Would it be possible to run the regression
tests with an older binary and the libraries from HEAD?  I would think
that would be a good test if we're unsure.

Of course, that would be problematic if the PG binaries use unexported
symbols in the libraries which changed between the releases (that's
rather nasty to do, imv, but it certainly wouldn't be the first time
I've seen it done in a project).  We could test some non-PG binaries in
that case, of course, but it wouldn't be as good a test.
Thanks,
    Stephen