Enforcing library version in a port Makefile?

[b. f.]

On 10/11/09, Alex Stangl <alex at stangl.us> wrote:
> On Sun, Oct 11, 2009 at 05:15:58AM +0000, b. f. wrote:
>> Alex Stangl wrote:

...

> 2. If user upgrades ports and gets lib.M+1, make fails because the exact
> match is no longer satisfied. (Porter's Handbook says you can use
> LIB_DEPENDS regular expressions like curl.[5-9] so this shouldn't be as
> much of a problem, at least not until it breaks years later on curl.10)

Yes, but this _should_ be the case, as changes in the major version
number of shared libraries should signal changes in the API/ABI, and
hence all dependent ports may need to be patched and all packages
rebuilt, and maintainers should check to see what changes, if any,
need to be made.

...

> I suspect this is what I shall have to do. Is this what all other port
> authors do in similar circumstances? It seems kind of a hackish
> workaround, especially if the library in question doesn't have a
> corresponding executable to list in RUN_DEPENDS. Do I force a library
> name into RUN_DEPENDS?

Sometimes this is done.  LIB_DEPENDS should really be called something
like SHARED_LIB_DEPENDS, or SO_DEPENDS, because of it's reliance on
ldconfig.  It doesn't apply to static archives, for example.  See the
www/dillo2 Makefile, where the recording of a dependence on a library
from x11-toolkits/fltk2 uses BUILD_ and RUN_DEPENDS rather than
LIB_DEPENDS.  Or, for an example involving pkgconfig data, see
Mk/bsd.xorg.mk, where various .pc files are added to BUILD_ and
RUN_DEPENDS.  The paths in the *_DEPENDS path:dir:target triplets
don't need to be the names of executables, but can be the names of any
file belonging to a port, although if path isn't the name of an
executable in the system PATH then you need to use a fully-qualified
pathname. See the ${deptype:L}-depends: target in Mk/bsd.port.mk for
the handling of the entries in *_DEPENDS.  If you need to use this
workaround, then don't forget to replace the relevant entries in
LIB_DEPENDS with corresponding entries in both BUILD_ and RUN_DEPENDS,
as in the examples I mentioned.

If you really only need to link against a shared library from the
port, but are forced  to use the *_DEPENDS variables rather than
LIB_DEPENDS to avoid an scons error, then yes, it is something of a
hack, but the fault is not with the ports infrastructure, but rather
with scons.  The major version number _is_ the most precise expression
of the dependency when linking with shared libraries.  In any event,
if it is necessary to do this, it only adds an extra line to the port
Makefile, and a small redundancy in one of the Makefile targets, so
the penalty is not too great.

b.