Date:        Thu, 13 Jan 2005 11:42:11 -0800 (PST)
    From:        "Jeremy C. Reed" <reed@reedmedia.net>
    Message-ID:  <Pine.LNX.4.43.0501131141050.27246-100000@pilchuck.reedmedia.net>

  | (Other than using a specific, one,
  | dependency, like imlib=1.9.14nb5, but we don't want to do that.)

For binary packages, "we" might not want to do that, but it is the
only correct thing to do.

For pkgsrc there isn't a big problem, as requirements can be updated to
exclude an incompatible version at the same time the incompatible version
is added (then because pkgsrc upgrades are supported only as all or nothing,
it all just works).

"we" don't want to "do that" for binary packages, because then we're faced
with the other problem - every binary package has to be replaced whenever the
smallest upgrade is made to a library - including (using just pkg names as
the dependency info, changes to comments, man pages, ...)

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

So, in the example given above, if imlib1.9.14nb6 is released, which correctly
installs the imview97.4 man page as imview97.3 (fictional name there folks!)
that clearly doesn't affect any ABI compatibility, and so would be marked as
equivalent to imlib1.9.14nb5 - then when the binary package requests exactly
1.9.14nb4, and pkg_add notes that 1.9.14nb6 is installed (or is present in
binary package form to be installed), it can be checked, and observed to be
an acceptable replacement for the required version, and the upgrade proceed.

On the other hand, if imlib1.9.15 appears, and that changes something about
the ABI (even possibly just by fixing a bug - dependent packages may be relying
upon the bug - working around it) then it would not be listed as being
compatible, and either an older imlib, or a newer dependent package would be
required.

fredb@immanent.net said:
  | Another way to get around that, is to depend on a specific file, that is, on
  | "lib/libgdk_imlib.so.10". 

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/libgdk_imlib.so.10.N 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).

kre