Re: pkgbase sometimes reported package vs. running kernel mismatches [ 1400505 vs. 1400501] (despite uname -KU producing 1400505 1400505)

Baptiste Daroussin <bapt_at_freebsd.org> wrote on
Date: Mon, 29 Jan 2024 08:18:00 UTC :

> On Sat, Jan 20, 2024 at 02:07:54AM -0800, Mark Millard wrote:
> > I got some odd reports of the likes of:
> > 
> > Newer FreeBSD version for package FreeBSD-tcpd-lib32:
> > To ignore this error set IGNORE_OSVERSION=yes
> > - package: 1400505
> > - running kernel: 1400501
> > Ignore the mismatch and continue? [y/N]: 
> > 
> > It was in a context with:
> > 
> > # uname -apKU
> > FreeBSD generic 14.0-STABLE FreeBSD 14.0-STABLE stable/14-n266448-e2b71e1490a3 GENERIC arm64 aarch64 1400505 1400505
> > 
> 
> This is a known issue which only happends due to the fact that the packages are
> built "WITHOUT_CLEAN=yes".
> 
> pkg does determine what is the running version of freebsd by analysing the uname
> binary elf notes.

Since the comparison is with uname -U like results
instead of with uname -K like results, should the
"- running kernel:" be worded to not mislead about
the type of version it is reporting?

I'll also note that if pkgbase gets/has the ability to
do just one of kernel vs. world in a given use, then
there would be other ways for a uname -K vs. uname -U
mismatches.

> Why the uname binary? because it is the only binary which is rebuilds each time
> sys/param.h is updated for uname -U.
> 
> The problem when sys/param.h is updated crt1.o is not being update and this is
> where the elf notes is added from. meaning with incremental build the note is
> never updated :(

If crtl.o ends up being updated, how much will rebuild
via (indirectly) depending on crtl.o ? Everything that
involves crtl.o ?

> See:
> https://reviews.freebsd.org/D43417

===
Mark Millard
marklmi at yahoo.com