Re: Removing find-prefix infrastructure

[Jonathan Perkin <jperkin%joyent.com@localhost>]

* On 2015-10-04 at 18:00 BST, David Holland wrote:

> On Thu, Oct 01, 2015 at 09:57:02AM +0100, Jonathan Perkin wrote:
>  > I'd like to propose removing the mk/find-prefix.mk infrastructure and
>  > related configuration.  This was required in a pkgviews world to find
>  > the installation prefix of a pkgsrc package, but since we removed
>  > pkgviews it is entirely redundant.
> 
> I object to this not on the grounds that FIND_PREFIX is a good
> mechanism (it's not) but that something like it is still needed.
> 
> To wit:
> 
>  >   BUILDLINK_PREFIX.pkg if pulled in via buildlink3.mk
>  >   LOCALBASE if pulled in via DEPENDS
> 
> hardwiring LOCALBASE is a step backwards.
> 
> Currently if you use DEPENDS instead of bl3 to pull in a package that
> has a builtin.mk, the builtin processing is skipped and the pkgsrc
> version is built unconditionally. This is suboptimal; in fact, I would
> be inclined to describe it as a bug, even though it's not readily
> fixable.
> 
> The thing is, assuming we eventually fix it, using LOCALBASE for the
> prefix of a package in DEPENDS is wrong, because it might be a builtin
> package.
> 
> So we should have DEPENDS_PREFIX.pkg or the like. Dunno how to make it
> work though :(
> 
> Maybe for now just insert DEPENDS_PREFIX.pkg?=$(LOCALBASE) at each
> such site and use DEPENDS_PREFIX subsequently? Then we can at least
> find them again later.

We've discussed this on IRC a little so I can understand where David
is coming from (we strongly disagree on DEPENDS vs bl3 which is
clouding the issue somewhat).  While I agree that in the future a
hypothetical buildlink4 which consolidates all our dependency methods
would be great, I do not want that to hold up this work which is by
and large independent of that.

I'm especially uneasy about adding a new DEPENDS_PREFIX variable when
we haven't even got to the design stage for bl4, let alone agreed that
this is the way we will refer to it.

Purely looking at numbers, my change increases the number of hardcoded
LOCALBASE references (ignoring mk/tools where we know we are
explicitly pulling in the pkgsrc version) from 1240 to 1325.

If and when we introduce a new buildlink4 infrastructure, there is
going to be a huge amount of work to migrate to it, and these changes
are a drop in the ocean.  Given the likelyhood of buildlink4 ever
happening, at least in a reasonable timescale, I oppose the
introduction of a new variable which increases the cognitive load and
number of variables we need to investigate when migrating packages, as
well as confusing things for new developers in the meantime.

Unless there are strong objections from a number of developers, I plan
to go ahead with the change as proposed, given the majority so far
have approved them as-is.

Cheers,

-- 
Jonathan Perkin  -  Joyent, Inc.  -  www.joyent.com