Address review feedback; use stat -h and stop asserting on hole reporting

Add a create-kernel-flavored-packages level of indirection instead, which looks
a little cleaner

In D52904#1208870, @imp wrote:

This is obscure enough we may want to have a comment..

Noted in IRC, but needs to wait a minute until I land bootstrap flua and make the UCL generation stuff use libucl to avoid breaking cross-build of package repo from older freebsd with a broken libucl -- I'll try to make some time today

Add licensw from ncurses for description theft, add more words

In D52308#1205084, @emaste wrote:

Something like the patch below (applied to each virtual_oss subdir) works. It's gross, but we're already doing this in e.g. lib/googletest/gmock/Makefile

OBE

It does make me wonder about all of the freebsd11_* bits in the same file that we use for pre-ino64 stuff, but my main concern is just fixing initgroups(3) for stable/15... we can always haggle on any other details later, if we need to.

This fixes the AX210 in my frame.work that previously made it through association and DHCP, then stopped passing traffic. Thanks!

Yeah, I'm happy with that, thanks. I recognize this is maybe not ideal for more flexible system construction (piece together your own based on a set and removing some), but IMO we should err on the side of caution and consider whether we can do something to enable better behavior with the final form of pkg groups.

In D52562#1200178, @ivy wrote:

In D52562#1200173, @kevans wrote:

I think my complaint is that, iirc, all of the metapackage dependencies are marked as automatic. As soon as they break the set as you suggest, the remainder would be subject to autoremove

right, but if you run pkg remove FreeBSD-set-devel followed by pkg autoremove, don't you expect all of clang etc. to be removed?

if the user does this by accident then runs pkg autoremove, they will see it's trying to remove FreeBSD-clang or whatever and can abort and rectify the situation.

I think my complaint is that, iirc, all of the metapackage dependencies are marked as automatic. As soon as they break the set as you suggest, the remainder would be subject to autoremove

Yeah, this seems fine to me. I did wonder for a second if the /rescue variants of shells do or should assume setugid behavior and avoid loading dotfiles in case something in the profile or other bits finds a way to make the shell unusable, but I didn't really convince myself.

Account for origin not existing, use an empty string; add tests

In D52498#1199266, @tamelingdaniel_gmail.com wrote:

@kevans can you have a look at your patch in bug 266496? (link)
I think nvlist_lookup_string can also return non-zero if one uses "origin" as key and the boot environment doesn't have an origin data set.

Whoops, good shout.

Thanks!

Can we preemptively add /src.conf to .gitignore if we do this?

In D52402#1196665, @jrm wrote:

Oh, sorry. One can't add screen.font=32x64 to /boot/loader.conf to get the Spleen fonts? I really can't tell much of a difference between the fonts on my system.

I would, however, hassle you a little bit over a commit message nit. One might look and notice that fortune-mod-bible has a dance to try and be compatible with different locations of strfile, but a little bit of archaeology reveals that @cperciva killed off the need for that back in 2015 (rG11d9aa670723f508821f2bf6980a555360783a80), so there's no remaining version of FreeBSD that will not have strfile in a stock configuration (and we don't really account for special pkgbase configurations today in ports, and maybe we won't tomorrow, either). I would proactively note in the commit message that the strfile dance found in other fortune data ports isn't necessary today to preempt concerns there.