Re: UPDATING stuff

On Mon, Aug 25, 2025 at 3:13 AM Alexander Leidinger <Alexander@leidinger.net>
wrote:

> Am 2025-08-25 10:44, schrieb Marcin Cieslak:
> > On Thu, 21 Aug 2025, Alexander Leidinger wrote:
> >
> >>>> COMPAT_FREEBSD14?  (Recently [gs]etgroups were changed, with
> >>>> compatibility syscalls moved to COMPAT_FREEBSD14).
> >>
> >> UPDATING only mentions VMM stuff for COMPAT_FREEBSD14. I give this a
> >> try tomorrow. But would this also affect the zfs dataset stuff?
> >
> > This thread could have been a simple UPDATING update.  I think this is
> > the fourth
> > time or so I have run into problems, because the changes were not
> > explained.
> >
> > UPDATING entry on VMM got only there after I've spent 2 days+
> > troubleshooting
> > my wifibox failures.
> >
> > When I read your message I was immediately thinking you might need
> > "COMPAT_FREEBSD14",
> > but, again, I couldn't find any obvious entry neither in the docs nor
> > in
> > the git log I was looking at.
> >
> > @glebus - maybe during the stabilization effort the changes done to the
> > tree
> > could be reviewed and documented?
> >
> >  - where the FreeBSD_version got bumped and why
>
> This is normally documented in
> https://docs.freebsd.org/en/books/porters-handbook/versions/ (intended
> to be updated at the time when the FreeBSD_versions is increased), but I
> can agree that the info there is a bit terse sometimes.
>
> >  - ABI changes
> >  - ....
> >
> > For example it could be useful to be able to find the information "what
> > does COMPAT_FREEBSD14 do exactly" in the UPDATING/release notes file.
> > Otherwise I can't be sure if I need that option or "is my system fresh
> > enough"
> > to remove it from the kernel.
>

It provides the system call interface as of FreeBSD 14. As new system calls
are added that replace old ones, they are moved to being conditional on
COMPAT_FREEBSD14. You should never remove the COMPAT_FREEBSDX when you are
on current X+1. It's a recipe for pain. FreeBSD 14 binaries still might not
always work (there are companion issues with shared library bumps for our
non-symbol-versioned libraries too: there you have to wait for new compat14
package and/or play libmap games since the major bump usually is compatible
enough to run most old programs but not always and not perfectly... libmap
is at best a stop-gap).


> What do you think about this?
> diff --git UPDATING UPDATING
> index ddb2e7603b2a..e197940c6431 100644
> --- UPDATING
> +++ UPDATING
> @@ -73,6 +73,12 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 15.x IS SLOW:
>          If you only have FreeBSD-sendmail installed for applications
> that
>          require libmilter, you can now remove it.
>
> +20250815:
> +       The [gs}etgroups(2)syscalls have changed. To maintain backwards
> +       compatibility with existing programs, you need COMPAT_FREEBSD14
> in
> +       your kernel config until all applications which use this are
> +       rebuild/reinstalled.
> +
>   20250815:
>          jemalloc 5.3.0 has been committed to the tree.
>

I'd make it stronger. We should proactively create a COMPAT_FREEBSD15 just
after the branch and add it to GENERIC. You 100% of the time want this if
you aren't updating every last binary on your system each and every time
you update. We should add that to our checklist to do eary, rather than
late, as needed. It shouldn't be buried in an obscure entry, but advice we
always give for everybody, all the time. GENERIC has it in there, which is
why most people won't see this issue.

Warner