tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



Taylor R Campbell <campbell+netbsd-tech-pkg%mumble.net@localhost> writes:

>> How do you propose to have bulk builds, so that
>> [...] 
>>   - assuming someone makes pgsql default on in gdal
>
> I believe we can put this assumption off indefinitely, based on the
> following comment you wrote in 2014 which has persisted for a decade:

It has, but I have recently actually started using it, so the use case
is clear, and I'm not sure the rest is as troubling as I thought.

But that's just one example.  Anything with libpq and libcurl is
trouble.

> So under all three of these scenarios the situation is not worse than
> before.  And in the one scenario you hit a problem in, with a certain
> combination of custom build options, the situation is improved by
> turning mysterious failure at run-time into obvious failure at
> build-time.

Agreed that what you want to do is an improvement.  I don't think it's
sufficient, but I am 100% fine with improvements.

1) It looks like KRB5_DEFAULT says "we are using this impl, only", and
if KRB5_ACCEPTED does not contain the default, the build fails.   The
comments don't quite say that.

2) Assuming I'm not confused about 1, Are you suggesting changing
KRB5_DEFAULT to mit-krb5?  If you do that, then ~nothing will use
heimdal, and we probably have to chase down and non-builtin-accept base
libs that link with heidmal (which is a latent bug anyway, if we support
KRB5_DEFAULT=mit-krb5 on NetBSD).  This was basically one of my options,
which I think you rejected.

If you don't change KRB5_DEFAULT, then I think the build of pgsql16 is
going to fail.

3) If I am confused about 1, then I don't see how this prevents linking
both.


Home | Main Index | Thread Index | Old Index