On Wed, 22 Mar 2006, Johnny Lam wrote:

> > > > I use IGNORE_RECOMMENDED=yes.
> >
> > > > -BUILDLINK_DEPENDS.expat+=	expat>=1.95.7
> > > > +BUILDLINK_DEPENDS.expat+=	expat>=2.0.0

If IGNORE_RECOMMENDED=yes, then ABI changes are the responsibility of the
user to manage.  That's one of the caveats of using IGNORE_RECOMMENDED=yes,
and it's why that is not the default setting.

> This is exactly the case here.  Between expat-1.95.x and expat-2.0.x, there
> was an ABI change that doesn't prevent packages from *building* correctly,
> though it causes problems with binary packages.  This is why I think the
> BUILDLINK_RECOMMENDED case already covers this.

It does.

> >   ... This [BUILDLINK_DEPENDS] variable should be set to the first version
> > of the package that had the last change in the major number of a shared
> > library or that had a major API change.

This makes no sense.  Why would we set RECOMMENDED at all in this case...?

> I still believe the whole BUILDLINK_RECOMMENDED concept is poorly-conceived
> and should be removed from pkgsrc, and that BUILDLINK_DEPENDS should be used
> as the guide currently says in the passages you excerpted above.

The way it's currently handled in pkgsrc is, in short:

BUILDLINK_DEPENDS: *API* changes.
BUILDLINK_RECOMMENDED: *ABI* and/or security-related changes.

This is a really important distinction, and has made pkgsrc very flexible
for "power users".  If we remove that distinction, we revert back to the
older incarnation of pkgsrc which forces the rebuild-the-world dances even
on those users who have the knowledge/experience to deal with such changes
in a more staged or progressive manner.

RECOMMENDED keeps a consistent package building environment for the default
settings (with IGNORE_RECOMMENDED=no), but allows users who Know What
They're Doing to use older, API-compatible dependency packages where they
want to do so.

-- 
-- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name>