LGTM again!

I think this part is OK now. That will at least ensure upgrades work, but not rollbacks.

I think this part is OK now. That will at least ensure upgrades work, but not rollbacks.

In D41893#955709, @emaste wrote:

...

maybe leave the directory->file case out for now and just handle the case that affects 13.2->14.0, so that people can apply that part to a 13.2 system and participate in 14 beta testing?

if [ -e ${BASEDIR}/${FPATH} ]; then
        if [ ${TYPE} = d ] && ! [ -d ${BASEDIR}/${FPATH} ]; then
                rm -f ${BASEDIR}/${FPATH}
        fi
fi

In D41893#955361, @emaste wrote:

Attempting to rollback:

# sh freebsd-update.sh rollback
Uninstalling updates...install: ///lib/casper/libcap_dns.so.2: No such file or directory
install: ///lib/casper/libcap_fileargs.so.1: No such file or directory
install: ///lib/casper/libcap_grp.so.1: No such file or directory
install: ///lib/casper/libcap_net.so.1: No such file or directory
install: ///lib/casper/libcap_pwd.so.1: No such file or directory
install: ///lib/casper/libcap_sysctl.so.2: No such file or directory
install: ///lib/casper/libcap_syslog.so.1: No such file or directory

In D41823#953876, @emaste wrote:

if we're going to make a change like this any reason not to go all the way and just make it a static inline bool?

Replace multiple expressions with one macro, and use logical operands in
that macro.

In D41823#953284, @mjg wrote:

is this the only occurence of this "error" in the tree?

this either should not be a warning altogether or the compile should ship a way to indicate "yes, this is what was meant".

Great, thanks!

In D41701#950363, @jhb wrote:

I upgraded an old riscv64 rootfs that had LLVM 14 and had these old files left around still. LLVM 16 installs the same set, so I assume the same set was present in LLVM 15.

BTW, it seems that none of the powerpc runtime libraries are listed for LLVM 15?

Note, this would also apply to devel/valgrind-devel.

It's usually not worth the effort of shrinking, if the array doesn't get larger than a bunch of pages. How large is this one anyway, in a typical scenario? A dozen, or maybe two dozen entries?

Abandoning this in favor of commenting out the dh.param line from freebsd.mc.

In D41232#940306, @gshapiro wrote:

I think a better way to go, as discussed in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248387 is to just remove the dh.param setting:

I'm tempted to remove the DH_PARAMETERS line from freebsd.mc completely and returning to using the built-in default (added in sendmail 8.15.2 after this line was added to freebsd.mc). However, I want to get John-Mark's input since he added the change in rev 256773:

https://svnweb.freebsd.org/base/head/etc/sendmail/freebsd.mc?revision=256773&view=markup

@jmg: How would you like to proceed?

If we can agree on that, I can make that change.

The time is indeed ripe for this setting to go, but the "toolchains can be a pain" line is maybe a little worrying? @sjg put it in, in rG0244ab1f26bcc, but that was a looooong time ago...

Indeed, bumping lib/clang/freebsd_cc_version.h is the way to force a bootstrap clang rebuild. The change to clang/lib/Driver/ToolChains/FreeBSD.cpp should also be upstreamed.

Hmm this might also allow us to revert rG5866c369e4fd917c0d456f0f10b92ee354b82279, which was added to work around https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256864 . As far as I remember, this only affected aarch64 though, and that is tricky for me to test.