joerg@britannica.bec.de wrote:
> Hi all,
> currently pkgsrc source builds and pkg_add usage can differ in the
> version of packages to use.

The difference also applies between two cases of binary installation:
1. via the bin-install target (directly), and 2. by pkg_add as a
prerequisite of something it is installing.  This exact issue came up
again recently in a conversation with Jeremy Reed (he asked about my
earlier bin-install patches) and I reviewed and added some to the "ideas
for future work" I suggested a year or so ago.  From my message to him:

--snip--
Hi, thanks for your interest.  It looks like 29741, 30928, 30929, 30954,
30955, and 30956 have all been committed already. For my most recent
nuke-and-reinstall I used the bsd.pkg.mk as distributed in
pkgsrc-2006Q1 and the functionality was there.

32128 is still a problem. [update: maybe it isn't; I was unable to
repeat it in a recent test, and the only CVS changes I saw were some
Coverity fixes, so maybe one of them caught the problem.]

Also still missing is the "slicker way, possible future work" in
[http://mail-index.netbsd.org/tech-pkg/2005/03/20/0023.html ~halfway]
--the idea that there shouldn't be two independent
ways of deciding what binary package to install, one implemented in
bsd.pkg.mk and one implemented in pkg_add for the automatic installation
of prerequisite packages, but the makefile should pass some information
to pkg_add to guide its decisions, and what pkg_add isn't able to figure
out on its own it should hand back off to the make system again.

In addition to the motivating example I gave in that e-mail, I have
discovered some more:

- I want some exceptions to "bin-install where possible", for instance I
 don't want the ftp.n.o binary of kdelibs because I want a kdelibs built
 with option cups.  I added code (not committed yet) that sets
 BINPKG_SITES=  for any package whose PKG_OPTIONS.foo differs from its
 PKG_SUGGESTED_OPTIONS. (I am typing this from memory so don't shoot me
 if I get some of the variable names wrong.)  This should have the effect
 I consider ideal: because the local packages/All directory is
 unconditionally prepended, if I already have a binary package stored
 locally (presumably built with my options), that is installed, but if
 not, no searching of ftp sites is done and that package is built from
 source with my options.

 But of course it doesn't work because if package bar, with unmodified
 options, is being installed from the ftp site, and depends on kdelibs,
 not yet installed, pkg_add just grabs kdelibs at the same time. Argh.
 So somehow pkg_add needs a way to consult the make infrastructure for
 each prerequisite it is about to automatically install, to decide if
 a binary install for that package is ok. Note that my original proposal
 in the e-mail needs to be extended somehow to cover this case.

- I set SUSE_PREFER=9.1 because the binary firefox I want to install
 won't run against 10.0. But that doesn't stop pkg_add looking
 for suse_foo>=9.1 and deciding that 10.0 satisfies the Dewey match.
 SUSE_PREFER is only known to the Makefiles.  It may be possible to
 cover this case with no extension to the algorithm I gave in the
 e-mail: if SUSE_PREFER causes the Makefile to generate required
 version numbers of exactly 9.1 (or 9.1nb*), then the algorithm requiring
 a match of both the @pkgdep-supplied and the makefile-supplied version
 patterns would do the right thing.

Maybe more of the responsibility for installing prerequisites needs to
be taken away from pkg_add and given back to the makefiles.  Perhaps
pkg_add could compile a list of needed but uninstalled prerequisites of
the package it is looking at, and invoke a secret make target that would
look through that whole list and determine the acceptable versions,
PKG_OPTIONS and PKG_PATHs for each, writing the results back to pkg_add.
If pkg_add has found a suitable binary package it can install that,
otherwise it can NAK that package and the make code builds it from source.

Of course this will not be a casual change, but I hope to make a case for
it if somebody gets funded by Google to rewrite pkg_install. The essential
point is that the intelligence to decide what versions to install should be
in only one place.
--/snip--

Since it looks like you /did/ get funded to rewrite pkg_install
(congrats :) I suppose this is the right time.  :)

-Chap