On Wed, May 24, 2006 at 03:12:24PM -0400, Chapman Flack wrote:
> 
> 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.

The major difference in that case is that bin-install does exact
matching and pkg_add looks for the latest version of a package.

> 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.

This description of the situation is IMO incorrect. pkgsrc normally
requires exact matches for bin-install as dependency and therefore
pkg_add wouldn't pick the best match. The only situation were this makes
a difference is when a newer version is available as binary package than
available in the tree. Often this is a broken dependency though.

> - 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.

I'd prefer to see options encoded in the binary package name instead,
which would fix this problem as well. It would need some extensions to
Dewey to match options, but that's a separate question.

> 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.

pkg_add should *never* consult the make system. The relationship if any
is "source build use pkg_add", but never the other way around. This
might be solvable by requesting pkg_add to be non-recursive, but in
general is a difficult problem. I'm not sure whether this can be solved
elegantly though. A combination of pkg-summary and a "reject" list (aka
don't install binary packages matching this pattern) might do this, but
frankly I'm not sure if it worth the trouble.

> - 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.

This is similiar to the PHP problem. For that it is solved by the
additional API requirement (php-4.4.*), but this is one of the situation
where we might want to extend the current Dewey patterns. The other
situation is being able to specify alternative matches (e.g. foo|bar as
pattern matches everything foo and bar matches, when in doubt, it
prefers packages matching foo). I think those are the only non-Dewey
pattern which can not be easily converted.

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

You are the second person which knows more than I do :-)

Joerg