not tested, but based on code inspection this looks fine. it's better not to add the correct package= tags on the new entries for now, instead we can do that for the entire file and test it all at once, since that's created subtle issues in the past.

./boot type=dir uname=root gname=wheel mode=0755 tags=package=bootloader,utilities

the described behaviour seems like clearly a bug in pkg. from the pkgbase side, i don't mind this change as a workaround, but i wonder what the correct fix is here; do we want a separate package for 32-bit clang, like clang-lib32? clibs-lib32 is 3MB, which is relatively tiny compared to clang itself, but i think i'd prefer not to have any mandatory dependencies from native packages to compat packages - you should be able to completely ignore compat if you don't want it.

i wonder: why is this in base, when pkg repository can only be built when pkg(8) is installed?

i decided that, rather than waste time adding more features to the current package build, i'd do the subdir-based rewrite that i've been planning for a while. that means you will be able to do something like this in packages/toolchain/Makefile:

In D55458#1276889, @ziaee wrote:

add -g from @ivy's comment on the mailing list.

tested on FreeBSD/amd64 13.5-RELEASE-p10, 14.3-RELEASE-p9, 15.0-RELEASE-p4, 16.0-CURRENT.

seems fine per previous discussion.

btw, i would also oppose adding this to build(7). manpages are not bug trackers. but if it belongs anywhere, it's there.

i dislike this change. freebsd-base(7) is about using packages, not about building them. if this belongs anywhere, it's in build(7).

In D55692#1274515, @emaste wrote:

Arguably the correct way to handle this would be for llvm-objcopy to be in a Clang (or LLVM) package, and objcopy to be in the toolchain package. It's currently a hard link though and would have to become a symlink instead.

one way i think this could cause problems is once we add pkgbase depends support to ports. say there's a port that specifically requires "llvm-objcopy", which package should it depend on to get that?

With LLVM_BINUTILS (default) these tools are included in the toolchain
package, including a link without the llvm- prefix. When LLVM_BINUTILS
is disabled only the llvm-prefixed versions are included, in the clang
package.

In D55630#1272973, @emaste wrote:

Maybe we can switch pkg to zstd?

i don't think the expanded scope of this diff is necessary. can we just document how to depkgbasify a system? that is the more important case, because we need to support people who install from disc1.iso with pkgbase and now need to depkgbasify to upgrade via installworld.

please also approve this for MFH, since it affects 2026Q1.

In D53484#1272636, @glebius wrote:

@ivy any ideas how to keep tests/sys/netinet/carp.sh working without routed?

re: MFC, you can MFC this to stable/14, even though it's too late for 14.4, we will be doing a 14.5 release.

i don't really want this review to turn into a debate over whether people should use RIP. the point is, people who do want to (and i'm aware some such people exist) can continue to do so, even using routed from ports if they really want.

is there any way we could consolidate this in a single Makefile rather than sprinkling it all over the place?

could we drop the "Example #" text, leaving e.g. ".Ss Install native compilers"? i don't think there's any benefit to numbering the examples, so this is more concise and equally readable.

i realise this diff was closed, but i want to point out for future reference that the correct way to convert a system to pkgbase is with the "pkgbasify" tool: https://github.com/FreeBSDFoundation/pkgbasify.

In D53484#1270635, @bms wrote:

It's not strictly necessary, but extra karma if you do. It looks like @cy is tracking that as ports/net/freebsd-routed anyway.

In D53484#1270040, @bms wrote:

Have you upstreamed any deltas from vendor to Vernon Schryver at Rhyolite.com (historically the out-of-tree routed maintainer) before performing removal?

this diff is basically dead, in the sense it won't be committed as it, but i was planning to factor out some smaller changes from it into their own diffs. did not have time yet...

one other thing that comes to mind is that pkg unregister was added in pkg 2.5.0, but, iirc, we only shipped 2.4.something on the 15.0 media. that won't be an issue for most people because you can just update pkg, but if you did an offline install of 15.0, and wanted to depkgbasify it before doing anything else, this wouldn't work. this will be a non-issue once 15.1 comes out and maybe it's minor enough to not be worth mentioning...

also: there are ports packages whose names begin with freebsd- (in lowercase); i think pkg is now case sensitive here, but someone should test that to make sure it won't randomly unregister those ports.

i would like to see a bit more prose to explain what this command actually does, probably in its own (sub)section. in particular, explain that it unregisters the packages without removing the files ("depkgbasify" is inside baseball terminology, users won't know what this means), and explain why you'd want to do that: mainly, because it prevents the package database from becoming inconsistent with the installed system. also, should mention that it's not easily reversible and would require the system be re-pkgbasified to undo.

D55412

the reason you get an empty lp package is that package=lp in mtree causes the directory to be unconditionally installed, so what you actually have is a package containing only that directory. we don't have a good solution to this right now; i think the right fix is that we would simply not build packages that only contain directories, but i haven't had a chance to look at this recently...

yes/no, anyone?

i put a fair amount of effort into not making bsdconfig a required part of the system and don't really want to see it come back. sysrc can't really be decoupled from bsdconfig, at least in the current implementation, because it's just a thin wrapper around what bsdconfig does.

this might be a better question for arch@, but at least to me, it doesn't make sense to keep code for removed architectures in the tree: either it will bitrot and stop working (in which case there's no point having it) or it will create effort to maintain it even though we don't support it.

In D54542#1250509, @cperciva wrote:

Please check with the CHERI people in case this will cause problems for them though -- I think they were holding off on pkgbase for a bit, and they're an important downstream for the project.

In D54542#1250509, @cperciva wrote:

Not sure if you were planning on MFCing this, but if you are we should discuss further before that happens. There has been some release build breakage in HEAD lately so I want to make sure all the issues are fixed there before anything gets MFCed.

okay, i don't object to this but i feel like (at some point in the future) we could have a better solution somehow.

the only purpose that RFC8781 mentions for having multiple PREF64s advertised is renumbering, in which case the lifetime of the deprecated prefixes should be set to zero. iiuc, this diff allows that by setting pref64lifetime0, pref64lifetime1, etc. - can i check i have that right?

are there any objections to landing this? i'd like to get started on multiple kernel support for bsdinstall, and it would be easier to get the other release changes in first.

ideally these should have a package= tag, but i'm leery about adding those without more testing, so that can wait until someone (me) comes along and adds package tags for everything in this file.

In D54702#1249777, @christos wrote:

@ivy Makefile.inc defines:

PACKAGE?=	sound

Is it a problem if the inclusion is removed from here?

i'd suggest adding a Fixes: trailer to the commit message, these are useful for people who maintain their own branches/forks.

i think you also want to add /usr/share/pkg/triggers. currently only usr.bin/mandoc installs a file here, but more things will in the future.

okay, but even if you know what you're doing, you still aren't going to get security updates :-)

this means people won't get security updates for up to a week. is that acceptable?

add releng since this touches release/ now.

• rebase after D54291
• fix the symlink sometimes having the wrong path
• make the symlink relative instead of absolute
• fix a wrong dependency for the kernel-dbg package
• since the install media uses kernels_autodetect=NO, explicitly set the kernel to GENERIC. the user can override this if they want the media to use a different kernel.

use a "." form for the release sets, so RELEASE_MEDIA_SETS_BOOTONLY
becomes RELEASE_MEDIA_SETS.bootonly. this makes it more clear that
it can be set for any media type.