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