Re: make replace

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Tue, Jul 06, 2010 at 04:00:30PM +0200, Marc Espie wrote:
> 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.

I didn't want to imply that. I don't exactly like the idea of pkg_add or
pkg_delete splitting up packages "on demand", but subpackages can be
used to the same result a priori. The OpenBSD remark was specific to the
idea of overriding the vendor version.

> 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.

This is something I specifically do not want to do as there are a number
of important cases where it fails, especially when you have to support
different executable formats (ELF, xcoff, Mach-O to name the popular
ones).

> (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)

The primary issue with ELF symbol versioning is that it is not too
wildly supported :) Otherwise I understand and agree with most of your
assessments, but not with all the resulting choices :)

Joerg