joerg@britannica.bec.de wrote:
> The major difference in that case is that bin-install does exact
> matching and pkg_add looks for the latest version of a package.

I think this picture is oversimplified. True, 'cd foo ; make bin-install'
will install an exact match of foo itself (which can only be out of date
if the pkgsrc tree is), but for prerequisites of foo, install-depends
preserves their specified Dewey wildcards and the sub-invocations of
bin-install pass these on to pkg_add.

> This description of the situation is IMO incorrect. pkgsrc normally
> requires exact matches for bin-install as dependency and therefore

Can you clarify what you mean by this? It seems possible that either I
am misunderstanding you, or we disagree as to what bsd.pkg.mk actually
currently does.

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

Under what circumstances can a binary package be available in a newer
version than the tree knows how to build? Only, I would argue, when the
local tree is out of date. But the converse situation is rather common,
during the time lag between updating of the tree and the upload of new
binary packages. There it is important to recognize that an available
binary package will satisfy the requirement rather than forcing a source
build of the very newest; that's why install-depends behaves as it does.

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

That would be another workable approach, but then it should not be
forgotten that pkg_add needs to know what combinations of options to
look for; this information cannot come solely from packages' internal
dependency lists, because site choices are involved; those choices are
currently recorded in mk.conf in a rich syntax parsable by make, and
I think it's important that they be recorded in /one/ place, and
honored consistently.

> 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

That is the question, and I'm not sure I'm yet convinced that's the best
answer to it. The make system is where the information is. Even if some
of the information gets written into the package files, the make system is
where it came from. It is recorded there in compact and sophisticated
ways using variables, arrays, conditional, inclusion, and looping
constructs that pkg_add does not currently duplicate and arguably should
not.

I don't think a user of the system will be especially impressed by the
philosophical purity of a separation, if the effect is a system that is
harder to use and less well integrated. Any way you slice it, the two
systems /are/ interdependent. They are interdependent for the inevitable
reason that binary builds are not always available for the packages you
need, in the versions and configurations you need, when you need them,
so a source build fallback is necessary, and yet source-building everything
may be prohibitively expensive, so it must be easy to have packages
binary-installed when available in the right versions/options.  The
philosophical decisions about how the parts of our system should or should
not interact need to be judged by how well the resulting total system
will perform under those inescapable demands.

> might be solvable by requesting pkg_add to be non-recursive, but in

That would be a solution, but it would have a higher performance cost
than one that does as much work as possible and appropriate in a single
invocation.

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

Right now we have a system where an objective that is really easy
to state--outfit my system with these specified packages, and whatever
they require, observing these specified constraints on versions and
options, and do it by binary installing whatever possible and building
the rest--is practically unachievable, and where the failure modes would
sometimes strike a new user as downright goofy.  If that can be improved
some, I think it could be well worth the trouble.

-Chap