the change looks fine assuming you tested it with the gcc build.

add an UPDATING entry

rebase, and also move compile_et (+ its awk scripts) to kerberos-dev

not tested but this looks fine in principle. i think this puts the files in the wrong package (they should be in a -dev package) but compile_et is already in the wrong package and i have another review open that redoes the krb5 packaging stuff, so i'll make sure it's right there.

In D51989#1187627, @cy wrote:

Please pay special attention to the makfiles outside of krb5/. Is it a wise idea to include headers from a relative path, i.e. ${.OBJDIR}... or use ${INCLUDEDIR}/private/krb5 to include autoconf.h?

In D51925#1187710, @des wrote:

I never asked you to move or drop any of the LIB_PACKAGE lines...

no one on arch@ has objected to this, so i'd like to move forward if possible - ideally we can land this for 15.0 as part of the MIT Kerberos switch.

address review feedback

add some comments to explain the strange list of krb5 directories

In D51914#1186878, @gshapiro wrote:

The changes look fine with one cosmetic exception: The open source release uses a lower case 's' when referring to 'sendmail'.

fix generate-ucl to not create a dependency from -lib to the base package

be a little more idiomatic

remove some dead code

add the missing ucl

In D51898#1186155, @des wrote:

Most internal libraries don't install anything. Some provide fake package names (PACKAGE=lib${LIB}).

this moves it to -utilities, which isn't where libutil lives (that's -runtime) but is the correct place for libutil++ in my opinion. libutil is only in runtime because some other binaries in runtime depend on libutil, but libutil++ doesn't include any libraries, so that can never be the case. to avoid bloating runtime, it should be in utilities.

In D51855#1185583, @hrs wrote:

I would suggest putting entries in /etc/defaults/rc.conf into each rc.d scripts, instead of maintaining rc.d/routed and defaults/rc.conf.d/routed separately.

In D51874#1185532, @cy wrote:

This is a lot to review.

further testing revealed that usr/lib/libkadm5clnt.a is also specific to Heimdal
(but not libkadm5clnt.so, which exists in both)

usr/lib/libkadm5clnt.so.11 should be in the Heimdal section

In D51859#1185120, @cy wrote:

I conditionally accept this revision. I don't think MK_GSSAPI makes no sense anymore since we're using the MIT KRB5 GSSAPI as our primary GSSAPI. lib/libgssapi was separate from Heimdal GSSAPI. This allowed us to install GSSAPI for use with other GSS providers not Kerberos. I don't think this holds true today. I'm willing to be convinced otherwise though.

closing in favour of D51859 which is a better fix

add UPDATING entry

also switch compile_et from KERBEROS_SUPPORT to KERBEROS in the Heimdal case

i intend to follow this with a revamp to OptionalObsoleteFiles for Kerberos that will be much simpler and also more correct. not having to deal with GSSAPI or KERBEROS_SUPPORT makes this a lot easier, both now and in the future.

landed in 084a3e1e033766eedb88b1cd99d786b4fd692931