Re: kerberos is the new sqlite: disable, force mit, or ?

[David Holland <dholland-pkgtech%netbsd.org@localhost>]

On Wed, Sep 04, 2024 at 07:46:58AM -0400, Greg Troxel wrote:
 > > For example, maybe something like:
 > >
 > > GSSAPI_REQD+=	credstoreext
 > > .include "../../mk/krb5.buildlink3.mk"
 > 
 > That is essentially open-coded right now, and lead to a bad failure.
 > pgsql16 direct-includes mit-krb5; if we added that variable and put
 > logic to require mit in krb5.buildlink3.mk, it would be the same.
 > 
 > The problem is that if one package needs this, and some other package
 > doesn't, and then you link libs from both together, it explodes.

There's a fundamental problem with anything where there's multiple
ways to get something, which is that the decision of what you're going
to do about it cannot be purely local.

In the case of builtin packages, for example, if A is used by both B
and C and then D uses B and C together, the decision of whether to use
the builtin A or not must be made once and take into account the
criteria of _both_ B and C. If the decision is made separately each
time when building B and C, and they apply different criteria such
that the decision comes out differently, both the builtin and
non-builtin versions of A appear and D is then broken.

The same thing happens if choosing between multiple implementations,
as in this case: the decision of which one to use needs to take the
entire dependency graph into account, and if it doesn't you get broken
packages or failed builds.

We don't have a good way of dealing with this and keep doing ad hoc
things to patch up individual cases that appear.

The result is that sometimes (e.g. with X packages) we're aggressive
about making sure only the canonical version is used (that is, builtin
packages that might maybe create problems are rejected out of hand),
which then aggravates everyone who wants a few basic X things on an
old machine and resents having to recompile things where their builtin
version is perfectly good for everything they need.

And sometimes we aren't, as in this case, and then we have broken
depending packages or cases where you need to explicit settings
(e.g. PREFER_PKGSRC) to get a consistent build or other such
problems. This also happens regularly with choice of C++ compiler.

(Why doesn't this come up all the time with curses? I guess because
it's rare for shared libraries to wrap curses and even rarer to try to
use two such and have them coexist.)

We really ought to figure out a proper general solution.

In the meantime, for this particular problem I think the best solution
is to create a placeholder package for kerberos (like we have
ghostscript to wrap the two possible ghostscript sources) which can
then depend on either builtin heimdal, pkgsrc heimdal, or pkgsrc
mit-krb5, then make everything else depend on it. That way you at
least always get only one.

There is no solution for the problem of needing mit-krb5 besides
building it and making everything that depends on kerberos use it, but
this way it's at least reasonably possible to make that happen
reliably.

(Or at least given a fix for pkg/57517. I am increasingly tempted to
commit my ugly workaround since nobody seems to have any better
ideas.)

-- 
David A. Holland
dholland%netbsd.org@localhost