Re: New kerberos packages & infrastructure changes

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

On 09.01.2011 02:17, Tim Zingelman wrote:
> I've finally got 2 new packages I think are ready (MIT separated the
> core from the apps into 2 distributions.)
> 
> As of right now, the two packages are set to be:
> 
> security/krb5           - krb5-1.8.3nb2
> security/krb5-apps  - krb5-apps-1.0.1
> 
> the alternative I guess would be to keep the mit- prefix on both of them.
>
> The good things about the name change include aligning the package
> name with the upstream distribution and also avoiding the case where
> someone updates from mit-krb5-1.4.2nb11 to the 1.8.3nb2 version and
> does not realize they also need the -apps package to maintain the
> kerberized inetd services, possibly resulting in lost connectivity to
> a remote system.  Also it allows the older well used package to remain
> as an option for some period of time.  (not installed together however
> as they conflict of course)

Is there any real reason to keep the previous package in tree?

> The bad things about the name change are that it causes a little
> confusion between mk/krb5.buildlink3.mk and
> security/krb5/buildlink3.mk  (I fix this by adding an underscore
> prefix to the KRB5_BUILDLINK3_MK variable in the internal
> mk/krb5.buildlink3.mk file making it _KRB5_BUILDLINK3_MK in addition
> to adding the new possible value of krb5 for KRB5_* variables) and
> perhaps someone fond of heimdal might object to the krb5 generic being
> used by the mit version of the code.

I'd keep the mit prefix, just to avoid confusion between "krb5" and
"heimdal". I agree, while the split will align the package with
upstream, I still prefer to have MIT appearing somewhere in the pkg
name. "krb5" is too generic, especially as NetBSD uses Heimdal.

Besides, if you change package name, updating mit-krb5 will still be
problematic once security/mit-krb5 will get deprecated, the user will
have to look for an update in security/krb5, without necessarily knowing
that a split happened in-between.

IMHO, indicate the split in MESSAGE, or mark -apps as an optional
dependency, and enable it by default?

> The kerberos infrastructure is a bit convoluted however, with
> mk/krb5.buildlink3.mk expecting users to set KRB5_DEFAULT to either
> mit-krb5 or heimdal and allowing packages to set KRB5_ACCEPTED (only
> one, print/LPRng-core does so.)  But also mk/bsd.pkg.use.mk accepting
> PKG_USE_KERBEROS=yes, but not as a result including
> mk/krb5.buildlink3.mk (6 packages specify this some expecting kerberos
> v4 and others v5 or both.)  Then mk/defaults/mk.conf describes
> defining the variable KERBEROS in mk.conf to specify use of kerberos,
> but states that said kerberos must be in /usr/lib and I see that while
> some packages look for this variable, none set it... and now I see it
> is marked as deprecated by mk/defaults/obsolete.mk.  There is is
> suggested that kerberos be enabled in a package using the options
> kerberos4 and/or kerberos... but a few packages use krb5 (or gssapi)
> instead, both of which are missing from
> mk/defaults/options.description.  Finally the platform default value
> for Darwin is set in mk/krb5.buildlink3.mk, but I think that should be
> done in mk/platform/Darwin.mk instead (as it is for HPUX.)
> 
> The few of you who are still reading must care at least a little about
> kerberos in pkgsrc :)  So any strong opinions?

I agree, the build infrastructure for Kerberos is quite a mess, although
I don't have any strong feeling on how it should be done.

I would not bother for kerberos4 as an option. "kerberos" seems fine,
but "gssapi" should be kept separate from "kerberos". There are not
exactly synonyms, although having GSS support often means Kerberos support.

So, unless the package has a direct dependency on Kerberos, without
GSSAPI in the loop, I would left "kerberos" as an option. Again, "krb5",
with a new package called security/krb5, will eventually confuse things.

> I propose adding the new krb5 packages without the mit- prefix, fixing
> mk/krb5.buildlink3.mk as described, and moving the Darwin default to
> the right place.
> The text in mk/defaults/mk.conf describing the KERBEROS variable
> should indicate it is deprecated and what the replacement is.
> 
> Beyond that these are these items I'm less sure about...
> It seems like PKG_USE_KERBEROS=yes should implicitly include
> mk/krb5.buildlink3.mk OR be marked as deprecated?

IMHO, deprecated.

> I think the packages using the krb5 option should change to use
> kerberos instead, but the gssapi option should probably be documented?

Yep!

> 
> Of course nothing will be changed until after the current code freeze ends.
> 

Thanks for working on that :)

-- 
Jean-Yves Migeon
jeanyves.migeon%free.fr@localhost