thanks @carlavilla for your comments, fixed them

adding explenation for kmods, fixing spelling error

@ziaee Do you think we can commit this as part of your list of doc changes needed for pkgbase? It's a start and I'd rather have something in the handbook that we can commit extension to before we try to add more to an ever growing review. Any thoughts? Do we need more reviewers?

Thanks Mark, that's really great info!
I added that to the REPODIR description in ENVIRONMENT.

clibs is fine imo

Thank you, this version is more useful.

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.

i'm really not sure runtime is the right place for this. libutil is only there because other things depend on it, but nothing can depend on libutil++ because it doesn't install anything (except manpages). but after thinking about it, clibs isn't the right place either, since it's not part of a C(++) runtime.

using X WITH Y as a single license entry makes sense to me, but as i mentioned on IRC it's not really clear if this is how you're meant to use the license field in pkg, so i'll wait to see what bapt says.

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.

with the caveats that ed said.

Yes, this can't possibly work -- the pkg you see there is built for the target, and it's just the bootstrap that downloads a suitable pkg from pkg.f.o. We don't have a version of pkg that could be used to cross-build packages at the moment, you'd need to bring your own (it is tested on Linux and macOS, IIRC).

In D51275#1176964, @ivy wrote:

i may be missing something but pkg doesn't ever exist in WSTAGEDIR, does it? it's not part of world since it comes from ports.

edit: or is this meant to call the pkg-bootstrap binary, but that will never work on non-FreeBSD platforms...

i may be missing something but pkg doesn't ever exist in WSTAGEDIR, does it? it's not part of world since it comes from ports.

change section to include the comments of bcr and ziaee

A few suggestions for conciseness. The text looks good so far, keep it up!

removed one "merges" like filis commented, changed part of the boot environment documentation which was not working.

removing one "merges"

correct small changes

Updating the documentation with the newest version including dch's part of the documentation.

Working on a PkgBase Chapter for the Handbook, this is not finished jet.
dch and i have started a git repository to work together:
https://github.com/lacherer/freebsd-doc/

In D41873#975105, @dfr wrote:

In D41873#975104, @manu wrote:

In D41873#975103, @dfr wrote:

In D41873#975075, @manu wrote:

I think that the question is should we have a FreeBSD-sh package or not.

I really like the idea of a FreeBSD-sh package - it covers what I'm trying to achieve here and avoids breaking up the carefully curated set of libs in runtime. We would have to be careful about upgrades to try to avoid leaving systems without /bin/sh.

There is always FreeBSD-rescue in case sh fails to upgrade

Good point. I will abandon this review and make one to add FreeBSD-sh.

In D41873#975104, @manu wrote:

In D41873#975103, @dfr wrote:

In D41873#975075, @manu wrote:

I think that the question is should we have a FreeBSD-sh package or not.

I really like the idea of a FreeBSD-sh package - it covers what I'm trying to achieve here and avoids breaking up the carefully curated set of libs in runtime. We would have to be careful about upgrades to try to avoid leaving systems without /bin/sh.

There is always FreeBSD-rescue in case sh fails to upgrade

In D41873#975103, @dfr wrote:

In D41873#975075, @manu wrote:

I think that the question is should we have a FreeBSD-sh package or not.

I really like the idea of a FreeBSD-sh package - it covers what I'm trying to achieve here and avoids breaking up the carefully curated set of libs in runtime. We would have to be careful about upgrades to try to avoid leaving systems without /bin/sh.

In D41873#975075, @manu wrote:

I think that the question is should we have a FreeBSD-sh package or not.

I'm not against *this* specifically, it will be nice to be able to have a shell-free nginx without FreeBSD-runtime but if we start doing this I think that we will end up moving all the libs in clibs.
I mean, it works with nginx but what about other programs ? Some that needs casper libs for example or gssapi ? Those are still in FreeBSD-runtime. Right now FreeBSD-runtime is only 8MiB so that's not that big.
I think that the question is should we have a FreeBSD-sh package or not.

Document the change to MANSPLITPKG

So where is this review? It seems to have wound down a bit.

I'll be updating this review and try to revive it.

I'm unsure which commit did it, but at a point near this commit the time taken by release builds drastically decreased. Before this close to 20 hours for an aarch64 cross-build, just over 6 after. Even though I can leave my build machine running, the decrease in latency is very nice. Thank you.

rebase

Looks ok,
Can you rebase your patch against latest main ?
Thanks.

addressed in latest update

address @manu's review

I don't think that the jail package should be vital.
Otherwise that looks good.

Push with a rebase and a few modif (PRERELEASE didn't worked).

addressed @swills' concerns.

I suggested this kind of approach in D27959 for kldxref; I think it's reasonable in that case, although perhaps we could indeed end up with something like if_em.test.ko

OK from manpages.

address @yuripv's comments.