security/krb5*: Client, libs, and server meta ports

[cy]

Summary

This is two commits. One to create krb5-{client, libs, server, samples} meta ports and the second to add support for these new meta ports to Uses/gssapi.mk.

The first commit to security/krb5*:

security/krb5*: Client, libs, and server meta ports

This commit creates a virtual split of the krb5 series of ports into
a libraries meta port (libs), client meta port (client), and server
meta port (server).

We build the entire krb5, removing the files not needed for individual
meta ports. This avoids having to build and maintain a complex set of
patches (which would certainly change from version to version) and it
avoids having to create our own build system.

Users can still build/install security/krb5 or security/krb5-121 to
install the entire krb5 port/package. Or users may install one or
more of the client, libs, and/or server meta ports.

This change does not affect the older security/krb5-120, scheduled for
deprecation.

The second commit to Uses/gssapi.mk:

Mk/Uses/gssapi.mk: Add support for krb5-client and krb5-libs

With the recent addition of client, libs, samples, and server
metaports, add support to allow ports to depend on krb5-libs or
krb5-client.

PR: 284709

Test Plan

Tested in a jail.

[diizzy]

Initial thoughts... (not tested in Poudriere)

While I like granuality I'm a bit on the fence about this one at least in its current form adds a lot of complexity to an already complex port, is there an underlying reason as I guess we don't save much disk space by splitting it up?
In case "everyone" is doing this has anyone talked to upstream about it? Having a quick look at upstream's code most appears to already have been separated internally.

Why is flavouring kept if there only one available? (this also probably breaks L151?)
I'm not a fan of the current plist hacking mainly because it's basically overrides existing framework and seems fragile. While personal preferance I guess I'd rather see each slave port handle their own a at least.

${PORT_OPTIONS:MLDAP}
This is "legacy" syntax, use LDAP_LIB_DEPENDS= instead

This also goes for adding multiple items to the same variable,

PLIST_SUB+=	KCLIENT="@comment "
PLIST_SUB+=	KLIBS="@comment "
PLIST_SUB+=	KSAMPLES=""

PLIST_SUB+=	KCLIENT="@comment " \
		KLIBS="@comment " \
		KSAMPLES=""

It's not a hard requirement but makes the tree more consistent in general and easier to follow

[cy]

In D49239#1124170, @diizzy wrote:

Initial thoughts... (not tested in Poudriere)

While I like granuality I'm a bit on the fence about this one at least in its current form adds a lot of complexity to an already complex port, is there an underlying reason as I guess we don't save much disk space by splitting it up?

Seems to be a popular demand by some who want OpenSSL to depend on cyrus-sasl to depend on krb5 creating a circular dependency. Though this split doesn't solve this, it may provide those who demand this split an additional tool to do so.

In case "everyone" is doing this has anyone talked to upstream about it? Having a quick look at upstream's code most appears to already have been separated internally.

Well, not exactly. Red Hat's .spec file builds the entire package, then copies their respective files into subdirectories before creating packages for each. My patch uses the same approach.

Why is flavouring kept if there only one available? (this also probably breaks L151?)

Actually two flavors. With and without OpenSSL support. Without OpenSSL support is default.

I'm not a fan of the current plist hacking mainly because it's basically overrides existing framework and seems fragile. While personal preferance I guess I'd rather see each slave port handle their own a at least.

It is fragile but avoids having to maintain four lists, using pkg-plist as the source of truth. And, working on the project to import MIT KRB5 into base to replace Heimdal, replacing their build system or patching it, significantly, is just as if not more fragile. At least this is easily tested within a jail.

${PORT_OPTIONS:MLDAP}
This is "legacy" syntax, use LDAP_LIB_DEPENDS= instead

So, would this work then? I'm trying to implement an if-then-else. The below would create an unconditional dependency on security/krb5-libs plus a conditional dependency on security/krb5-libs@ldap. Would that really work?

LIB_DEPENDS+= libkrb5.so:security/krb5-libs
LDAP_LIB_DEPENDS= libkdb_ldap.so:security/krb5-libs@ldap

This also goes for adding multiple items to the same variable,

PLIST_SUB+=	KCLIENT="@comment "
PLIST_SUB+=	KLIBS="@comment "
PLIST_SUB+=	KSAMPLES=""

PLIST_SUB+=	KCLIENT="@comment " \
		KLIBS="@comment " \
		KSAMPLES=""

I suppose a person could do this. It's just a matter of style (after working on src Makefiles for a while). The former "feels" a bit cleaner.

It's not a hard requirement but makes the tree more consistent in general and easier to follow

Thanks for the review. Can you answer the LDAP_LIB_DEPENDS question above. I'd prefer to do it that way but it looks like it will depend on krb5-libs unconditionally even when LDAP is enabled. And, which one would win?