Re: An odd vital FreeBSD-set-* result? [ release/packages/sets/*.ucl vs. FreeBSD-set-* update timing ]

From: Mark Millard <marklmi_at_yahoo.com>
Date: Sat, 20 Sep 2025 01:42:08 UTC
On Sep 19, 2025, at 11:04, Mark Millard <marklmi@yahoo.com> wrote:

> On Sep 19, 2025, at 10:32, Lexi Winter <ivy@freebsd.org> wrote:
> 
>> Mark Millard wrote in <D00275AE-2E13-45AC-AAF4-D5410E07553E@yahoo.com>:
>>> But the following indicates that the cached *.pkg files themselves
>>> agree with the just-4-vitals status:
>> 
>> do you build your packages with "make update-packages"?  if so, can you
>> try deleting your ${REPODIR} and rebuilding, so all packages are
>> recreated?
> 
> I never build packages (and I've not done any system builds
> in a vey long time, never having packaged one that I did build):
> what I use for pkgbase testing is official upstream material
> from https://pkg.freebsd.org/ via pkg-static that is using:
> 
> # cat /usr/local/etc/pkg/repos/FreeBSD-base.conf 
> FreeBSD-base: {
>    url: "pkg+http://pkg.FreeBSD.org/${ABI}/base_latest",
>    mirror_type: "srv",
>    signature_type: "fingerprints",
>    fingerprints: "/usr/share/keys/pkg",
>    enabled: yes
> }
> 
> There is no build of mine to be oddly done in some way.
> 
>> i'm wondering if adding the vital flag (but not changing anything else)
>> doesn't cause update-packages to actually update the package.
> 
> Unsure.

Reminder, with a note added:

QUOTE (with a  note added)
The following package(s) are locked or vital and may not be removed:

FreeBSD-set-base
FreeBSD-set-devel
FreeBSD-set-minimal
FreeBSD-set-minimal-jail

[ NOTE: Missing: FreeBSD-set-lib32 , FreeBSD-set-src , FreeBSD-set-tests ]

Deinstallation has been requested for the following 10 packages (of 0 packages in the universe):

Installed packages to be REMOVED:
FreeBSD-set-base-dbg: 16.snap20250918100450
FreeBSD-set-devel-dbg: 16.snap20250912210739
FreeBSD-set-kernels: 16.snap20250917214757
FreeBSD-set-kernels-dbg: 16.snap20250912210739
FreeBSD-set-lib32: 16.snap20250912210739
FreeBSD-set-lib32-dbg: 16.snap20250912210739
FreeBSD-set-minimal-dbg: 16.snap20250918100450
FreeBSD-set-minimal-jail-dbg: 16.snap20250917214757
FreeBSD-set-src: 16.snap20250916221226
FreeBSD-set-tests: 16.snap20250916221226

Number of packages to be removed: 10

Proceed with deinstalling packages? [y/N]: y
[1/10] Deinstalling FreeBSD-set-base-dbg-16.snap20250918100450...
[2/10] Deinstalling FreeBSD-set-devel-dbg-16.snap20250912210739...
[3/10] Deinstalling FreeBSD-set-kernels-16.snap20250917214757...
[4/10] Deinstalling FreeBSD-set-kernels-dbg-16.snap20250912210739...
[5/10] Deinstalling FreeBSD-set-lib32-16.snap20250912210739...
[6/10] Deinstalling FreeBSD-set-lib32-dbg-16.snap20250912210739...
[7/10] Deinstalling FreeBSD-set-minimal-dbg-16.snap20250918100450...
[8/10] Deinstalling FreeBSD-set-minimal-jail-dbg-16.snap20250917214757...
[9/10] Deinstalling FreeBSD-set-src-16.snap20250916221226...
[10/10] Deinstalling FreeBSD-set-tests-16.snap20250916221226...
END QUOTE

Overall:

# find -s /var/ \( -name 'FreeBSD*-src-*' -o -name 'FreeBSD-set-*' \) -print | grep -v "\~" | sed -e 's@^.*\(FreeBSD-.*-\(16\..*$\)\)@\2 \1@' | sort -r
16.snap20250918100450.pkg FreeBSD-src-sys-16.snap20250918100450.pkg
16.snap20250918100450.pkg FreeBSD-src-16.snap20250918100450.pkg
16.snap20250918100450.pkg FreeBSD-set-minimal-dbg-16.snap20250918100450.pkg
16.snap20250918100450.pkg FreeBSD-set-minimal-16.snap20250918100450.pkg
16.snap20250918100450.pkg FreeBSD-set-devel-16.snap20250918100450.pkg
16.snap20250918100450.pkg FreeBSD-set-base-dbg-16.snap20250918100450.pkg
16.snap20250918100450.pkg FreeBSD-set-base-16.snap20250918100450.pkg
16.snap20250917214757.pkg FreeBSD-set-minimal-jail-dbg-16.snap20250917214757.pkg
16.snap20250917214757.pkg FreeBSD-set-minimal-jail-16.snap20250917214757.pkg
16.snap20250917214757.pkg FreeBSD-set-kernels-16.snap20250917214757.pkg
16.snap20250916221226.pkg FreeBSD-set-tests-16.snap20250916221226.pkg
16.snap20250916221226.pkg FreeBSD-set-src-16.snap20250916221226.pkg
16.snap20250912210739.pkg FreeBSD-set-lib32-dbg-16.snap20250912210739.pkg
16.snap20250912210739.pkg FreeBSD-set-lib32-16.snap20250912210739.pkg
16.snap20250912210739.pkg FreeBSD-set-kernels-dbg-16.snap20250912210739.pkg
16.snap20250912210739.pkg FreeBSD-set-devel-dbg-16.snap20250912210739.pkg

Compare/contrast with the update to 7
release/packages/sets/*.ucl files, via:

QUOTE
author Lexi Winter <ivy@FreeBSD.org> 2025-09-17 20:12:21 +0000
committer Lexi Winter <ivy@FreeBSD.org> 2025-09-17 20:14:18 +0000
. . .
packages: Mark all sets as vital
END QUOTE

20250912210739 for FreeBSD-set-lib32 is well before 2025-09-17 20:14:18 +0000.
20250916221226 for FreeBSD-set-src   is also.
20250916221226 for FreeBSD-set-tests is also.

So: those 3 were not updated by making the
changes to the matching release/packages/sets/*.ucl

The other 4 are all after 2025-09-17 20:14:18 +0000
and so were updated --but possibly for other reasons
than the matching release/packages/sets/*.ucl change.

It looks like /usr/src/ indicates what should have
happened (and, so, was correct).

Instead it is the lack of updating to the 3
FreeBSD-set-*.pkg files that is evidence of the
type problem, whatever its details.

>>> Also of note is the lack of a new-line between the prior } and the
>>> name: for most of the above. An example of a surrounding context is:
>>> 
>>> categories: [
>>>   "base"
>>> ]
>>> annotations: {
>>>   FreeBSD_version: "1600000"
>>> }name: "FreeBSD-set-base-dbg"
>>> origin: "base"
>> 
>> it looks the UCL output from 'pkg info' doesn't have a trailing newline.
>> i think this is a pkg(8) bug, but it shouldn't have anything to do with
>> this issue.
>> 
>> to confirm, this is the full output i get for the set-src package, using
>> 'echo' to force a trailing newline:
>> 
>> # pkg info -R -F /build/packages/base/FreeBSD:16:amd64/latest/FreeBSD-set-src-16.snap20250919160159.pkg; echo
>> name: "FreeBSD-set-src"
>> origin: "base"
>> version: "16.snap20250919160159"
>> comment: "System source code"
>> maintainer: "re@FreeBSD.org"
>> www: "https://www.FreeBSD.org"
>> abi: "FreeBSD:16:amd64"
>> arch: "freebsd:16:x86:64"
>> prefix: "/"
>> flatsize: 0
>> licenselogic: "single"
>> licenses: [
>>   "BSD2CLAUSE"
>> ]
>> vital: true
>> desc: "This metapackage installs source code for the base system and kernel."
>> deps: {
>>   FreeBSD-src: {
>>       origin: "base",
>>       version: "16.snap20250919160159"
>>   },
>>   FreeBSD-src-sys: {
>>       origin: "base",
>>       version: "16.snap20250919160159"
>>   }
>> }
>> categories: [
>>   "base"
>> ]
>> annotations: {
>>   FreeBSD_version: "1600000"
>> }
>> #
>> 
>> other than the vital flag, does this match what you have?
> 
> Again: the following are from upstream, official builds, not
> from me building or packaging anything. Note that it is not
> the same snapshot that you show: It is from when I happened
> to fetch the official materials of the time. But you can see
> the exact snapshot naming, including the timestamp part
> below.
> 
> # find -s /var/ -name 'FreeBSD-set-src*.pkg' -print
> /var/cache/pkg/FreeBSD-set-src-16.snap20250916221226.pkg
> /var/cache/pkg/FreeBSD-set-src-16.snap20250916221226~cfde358ad0.pkg
> 
> # pkg info -R -F /var/cache/pkg/FreeBSD-set-src-16.snap20250916221226~cfde358ad0.pkg ; echo
> pkg: Warning: Major OS version upgrade detected.  Running "pkg bootstrap -f" recommended
> name: "FreeBSD-set-src"
> origin: "base"
> version: "16.snap20250916221226"
> comment: "System source code"
> maintainer: "re@FreeBSD.org"
> www: "https://www.FreeBSD.org"
> abi: "FreeBSD:16:amd64"
> arch: "freebsd:16:x86:64"
> prefix: "/"
> flatsize: 0
> licenselogic: "single"
> licenses: [
>    "BSD2CLAUSE"
> ]
> desc: "This metapackage installs source code for the base system and kernel."
> deps: {
>    FreeBSD-src: {
>        origin: "base",
>        version: "16.snap20250916221226"
>    },
>    FreeBSD-src-sys: {
>        origin: "base",
>        version: "16.snap20250916221226"
>    }
> }
> categories: [
>    "base"
> ]
> annotations: {
>    FreeBSD_version: "1600000"
> }
> #
> 
> The snapshot name and the vital line's status seem to be
> the differences between your example and mine.


===
Mark Millard
marklmi at yahoo.com