Maintenance: update --with-mit-krb5 detection

[yadij]

[kinkie]

I move that we remove any configure magic targeting Solaris.

Let's face it, the likelihood of Squid being deployed on Solaris is next to zero. We haven't been able to do any tests on Solaris ever since Oracle decided they didn't want the FOSS community to work on it. Oracle can port it themselves, if they want, or they can contact us with donations of licenses or even better cloud compute time to tinker with it. Until that happens, we have our hands full with other platforms that are much more likely to be useful

[rousskov]

I move that we remove any configure magic targeting Solaris.

If admins can workaround the lack of removed magic with ./configure parameters (and such), then you have my full support to remove all the corresponding tricks (in a dedicated PR). The same principle goes for any other exotic environment or very old versions of popular environments: Our ./configure should have no unnecessary environment-specific workarounds, especially when those workarounds only apply to rarely seen cases. Many of such workarounds come with a significant cost to Squid code and Squid developers. They are misplaced and should be moved to documentation and support channels.

the likelihood of Squid being deployed on Solaris is next to zero.

Currently, that (largely irrelevant IMO) probability is close to one because we still have relatively fresh bug reports filed by folks running Squid on Solaris:

• 2023-10-27: Bug 5314: segfaults in ModDevPoll Comm::SetSelect()
• 2023-10-27: Bug 5312: ModDevPoll aborts on startup if fd_limit is less than OPEN_MAX
• 2022-09-30: Bug 5242: WCCPv2 seems broken in Ssquid 5.4, 5.5, 5.7
• 2020-08-23: Bug 5073: Compile error: index was not declared in this scope
• 2018-05-31: Bug 4857: Polish ModDevPoll.cc
• 2018-01-25: Bug 4813: Wrong CPU statistics in cachemgr
• 2017-03-15: Bug 4686: assertion failed: client_side_reply.cc:1641: "reply == NULL"
• 2017-02-18: Bug 4673: assertion failed: http.cc:1576: "!Comm::MonitorsRead(serverConnection->fd)"
• 2017-01-17: Bug 4662: build errors with LibreSSL 2.4.4
• 2017-01-16: Bug 4661: 4.0.17 compile error 'warning: _XPG4_2 redefined' with GCC on Solaris 10

However, the frequency of such reports is clearly low these days. For comparison, there were ~25 such reports in 2016 year alone.

[yadij]

IMO we have enough interest to keep it around, but not enough to waste our resources spending more time on this discussion. The shuffling (non-)change in this PR at least makes the configure.ac logic easier to work with regardless of how the Solaris situation goes. We just need to accept that this is "Good Enough" (not actively breaking anything new) and let those with Solaris interest+testing ability work on further improvements.

[rousskov]

Francesco: I move that we remove any configure magic targeting Solaris.

Alex: If admins can workaround the lack of removed magic with ./configure parameters (and such), then you have my full support to remove all the corresponding tricks (in a dedicated PR).

Amos: IMO we have enough interest to keep it around

I do not see enough interest to keep any Solaris configuration magic that can be replaced with custom ./configure parameters and such. I have posted the indicators of some Squid-on-Solaris interest in general (that I know about), but that interest is not sufficient to keep unnecessary magic IMO.

Amos: but not enough to waste our resources spending more time on this discussion.

IMO, Solaris magic removal (i.e. the topic of this discussion) has the potential to save a lot of resources long-term. The result depends on us, of course, but it can result in a very positive outcome rather than waste.

Amos: The shuffling (non-)change in this PR at least makes the configure.ac logic easier to work with regardless of how the Solaris situation goes. We just need to accept that this is "Good Enough" (not actively breaking anything new) and let those with Solaris interest+testing ability work on further improvements.

FWIW, this discussion has not (and does not have to in the future) block this PR.