Subject: Re: make update hell
To: Jeremy C. Reed <>
From: Todd Vierling <>
List: tech-pkg
Date: 10/15/2004 20:05:10
On Fri, 15 Oct 2004, Jeremy C. Reed wrote:

> I believe that BUILDLINK_DEPENDS should only be increased if the SONAME
> changes. So in the recent libtool improvements, instead of bumping
> BUILDLINK_RECOMMENDED really all the BUILDLINK_DEPENDS should have been
> increased (and BUILDLINK_RECOMMENDED removed because would be redundant).

In a perfect world, I agree.  This is precisely how RECOMMENDED should be
used, or to put it another way:

BUILDLINK_DEPENDS: earliest ABI-compatible version of package

BUILDLINK_RECOMMENDED: earliest "security-fixed" version of package, always
    >= the version in BUILDLINK_DEPENDS

The reason I chose BUILDLINK_RECOMMENDED and *not* BUILDLINK_DEPENDS for the
libtool sweep was because it offered a way to let users keep using their old
shlibs as a transition scheme, with the caveat that built package may be
using the "wrong" soname compared to what a fresh build of the dependency
would provide.  Thanks to the way .la files work, this was a usable
compromise, and seemed to be a way to address some of the update headaches
for "production" environments, given the >2200 packages involved.  I would
not choose such a compromise for a limited dependency tree bump.

BTW, this shouldn't have broken anything for the normal case, but I highly
suspect that the "breakage" you saw was because you were trying to use "make
replace".  I did mention that "make replace" would not work correctly after
the libtool bump sweep until all affected packages were updated fresh.

> I suggest that IGNORE_RECOMMENDED be renamed "USE_RECOMMENDED" and the
> usaged reversed?

The intent seems to be correct in the current implementation.

> Anyone else use IGNORE_RECOMMENDED (as it is) successfully over several
> weeks? Anyone using it since it worked (mid August)?

It's been in use it on my i386 server without problem, and I used it as a
transition scheme during the libtool sweep.  (I still have a couple packages
with old SONAMEs that I'll rebuild only when I have the time to down the
server for a whole pkg tree rebuild.)

> I don't see @blddep being used though.

The issue is, AFAICT, that @blddep should be represented as a dewey
dependency, so that (even if only enforced via a pkg_add option) it could
function as a proper dependency constraint.

-- Todd Vierling <> <>