[PROPOSAL] Require builtin or system krb5 libs

Jelmer Vernooij jelmer at samba.org
Sun Jan 1 14:47:46 MST 2012


Am 01/01/12 04:36, schrieb Andrew Bartlett:
> On Sat, 2011-12-31 at 09:30 -0500, simo wrote:
>> On Sat, 2011-12-31 at 20:58 +1100, Andrew Bartlett wrote:
>>> Back in October, I wrote the the list suggesting that we should adopt an
>>> explicit policy that we require at least some level of Kerberos support
>>> to build Samba:
>>>
>>> On Mon, 2011-10-24 at 21:03 +1100, Andrew Bartlett wrote:
>>>
>>>> I would actually like us to consider if there are systems that we care
>>>> about without krb5-devel, and which cannot use the waf build.  If we
>>>> could always expect at least some kind of Kerberos library (internal or
>>>> system heimdal from the waf build, or any system from autoconf), we
>>>> could make our code much simpler in parts.
>>> I would like to make that a firm proposal.  For me at least, Samba both
>>> 3.5.11 and current master do not compile without krb5-devel.  As such,
>>> it seems no testing is done on systems without a kerberos library, and
>>> our users have not been inconvenienced by this requirement.
>>>
>>> Therefore, as we have a way to build Samba without a system kerberos
>>> (the waf build), I would like us to require that users either build with
>>> waf, or build with a system krb5-devel.
>>>
>>> Doing so would remove a lot of dead, untested #ifndef HAVE_KRB5 stub
>>> functions, and make our code easier to follow and simpler to develop.
>>>
>>> What do others think?
>> I am ok in always requireing kerberos libraries, but given we are making
>> a requirement I would go further and specify a minimum MIT Kerberos or
>> Heimdal Kerberos versions.
>>
>> Testing for specific functionality to be present instead of version
>> numbers is also ok.
> I strongly agree.  Kerberos libraries have come a long way in the last
> decade, and being able to rely on that would be very, very useful.
+1, both on this proposal and for specific (minimum)  system 
versions/functionality.

Cheers,

Jelmer


More information about the samba-technical mailing list