Not sure I like that but I could be ok if people wants this. Is this package vital ?

My rational for putting them into runtime is that if anything goes wrong and only runtime and clibs are upgraded you can boot to single user and debug network functionality.

I don't remember why I put it in -runtime back then

In D52494#1198878, @imp wrote:

So does this work with our arm64 boards that use a u-boot provied EFI image? The comment are for this case, though we really only care about the last u-boot or two, not ancient history.

I like it that way but if the majority of our users wants this I'll not complain :)

So they will be in kerberos-lib-dev right ?

In D39758#1182965, @ivy wrote:

is this still relevant? i don't think it's correct (anymore): the first kernel in KERNCONF is always installed to /boot/kernel because that's where the default kernel is expected to be. changing that would require updating a load of stuff (like loader) to look somewhere else instead.

In D51756#1182294, @ivy wrote:

it's a bit of an odd package since there's no reason to install it at all unless you're hacking on src, and i'm not sure we have any precedent for that. does it make sense to have a FreeBSD-src-man package? there are a few more things that we could perhaps move there, like src.conf(5). however, we'd need to make it not depend on FreeBSD-src.

Not sure if clibs is the best package for this, maybe it fits better in runtime (which have libutil.so and the man in the -man) ?

In D51486#1176225, @emaste wrote:

Seems fine to me. On my laptop gssd is only 36K though and maybe it doesn't warrant a specific package?

Commiting https://reviews.freebsd.org/D51420 would be much better for everyone.

In D51420#1174719, @ivy wrote:

another argument in favour of not changing the package name is upgrades: after we switch MIT Kerberos to the default, everyone who has FreeBSD-kerberos installed needs to remove it and install FreeBSD-krb5 instead. however, there is no mechanism in pkg(base) to do this automatically, or even notify the user that they need to do so. instead, what will happen is that people will end up with the obsolete/orphaned FreeBSD-kerberos installed on their system, which is going to cause confusion.

now, i accept this is an issue in pkgbase that we should probably fix, but for now it's not fixed, and keeping the same package name avoids this issue entirely.