Subject: Re: Shared object not found - but all dependencies are ok ?!
To: None <>
From: Frederick Bruckman <>
List: tech-pkg
Date: 01/14/2005 17:26:46
In article <>,
	Robert Elz <kre@munnari.OZ.AU> writes:
>     Date:        Thu, 13 Jan 2005 11:42:11 -0800 (PST)
>     From:        "Jeremy C. Reed" <>
>     Message-ID:  <>
> A solution to this, is for an upgraded package to explicitly state which
> (earlier) versions it is binary compatible with (ie: ABI compatible in a
> forwards direction upgrade).

...or rather, synthesize an ABI version, so we don't have record all the
history in every package.

> said:
>  | Another way to get around that, is to depend on a specific file, that is, on
>  | "lib/". 
> Actually, no.   That doesn't solve the problem at all.   It reduces the
> effect of the problem (stuff like man page updates clearly just vanish as
> issues), but requiring a specific library file isn't enough.
> That one just refers to one of the lib/ actual libraries,
> and there's no guarantee that they're all equally useful for any particular
> binary application.   The test would have to be for that particular minor
> version of the library - and then you're back at "upgrade everything" - so
> this has really made no difference at all (though it is better, when the
> dependency is a library, than the current scheme).

OK, so we have to depend on an ABI version, with the minor, at least,
being parsed as a number.  So (to make this concrete), packages built
against gdk-pixbuf might get "@libdep libgdk_imlib-so-10-10" at
"pkg_create" time.  To install this package, "pkg_add" would take the
open-ended dependencies as hints, until it found a package that had,
in its "+CONTENTS", "", with N greater than "10".

This could go further, divorcing the ABI provided from the
filename, somewhat, so the library package might have "@libprovides
lib_gdk-so-10-10", with that automatically computed at package creation
time by default, but with some provision to override for those packages
which bump minor names gratuitiously.