Re: make replace

[Marc Espie <espie%nerim.net@localhost>]

On Tue, Jul 06, 2010 at 02:20:57AM +0200, Joerg Sonnenberger wrote:
> (c) Subpackages can make (2) less painful on common platforms like ELF
> systems. The idea mentioned by the OpenBSD folks at pkgsrcCon to
> forcefully override the major version created by libtool in combination
> with subpackages can dramatically reduce the impact of major version
> bumps. Basically, next to the PKGREVISION a package could have something
> like MAJOR_VERSION_OFFSET, that gets added to all major versions of
> libraries in that package. This offset is monotonically increasing and
> if shared libs (libfoo.so.*, not libfoo.la and not libfoo.a) are in a
> separate subpackage, it would allow removing the development files etc
> of png, install the new files and all existing packages would still
> work. It doesn't help all cases, but it can make the process a lot less
> painful.

Actually, we don't do it with subpackages.
We do tags libraries with special keywords (@lib for the library, and
@wantlib for the requiring package), and pkg_add knows about those: it does
all the split-up work automatically during updates, so that we end up with
packages that contain only the shared libraries.

The other magic is to register what version of which shared libraries was used
to build a given package (happens during pkg creation), we just have a helper
script that walks the DESTDIR-installation through objdump to automate the
discovery of library "stems" (e.g., just the name), and then pkg_create
matches that against installed libraries.

It was a conscious decision to make package tools and our ports tree totally
aware of shared libraries. I had come to this conclusion while looking at
update possibilities (and afterwards, looking at other package systems,
such as rpms, comforted me in that conclusion).  The really hard part was
indeed to take control of all shared library versions.  This is painful,
because libtool only accounts for a portion of them (we have cmake under
control as well, and some patches for a lot of the rest).

Maintenance is always a bit painful: in general, upstream are linux idiots
who don't understand what an ABI is. So they bump library versions in a
VERY haphazard way.  If you follow them (through MAJOR_VERSION_OFFSET),
you *will* create a lot of churn during updates.

(stuff like ELF symbol versioning only goes so far... since it quickly
gets entangled as soon as a library exports some internal structs, and some
other library starts using those)

As far as your average package maintainer goes, you have to help him/her,
because he doesn't understand ABI issues... and automated tools only help
to a point...  each time a structure changes, and is exposed in the ABI,
the major version number should change. There are only two ways to discover
that:
- careful inspection of the source (most specifically header files)
- major breakage after an update which assumed the library didn't change.

Yes, it's a lot of work.

I would very much welcome more people being aware of those issues, and
actually trying to teach the various upstream people about ABI consistency,
so that eventually it takes less of a toll...