What version of pkg?

v2.6.2 (quarterly port packages)
v2.7.5 (latest --a.k.a. default-- port packages)

Something else?

What version of the FreeBSD OS?

RELEASE: 14.3, 14.4, 15.0, 15.1
STABLE: 14, 15
main: 16

Why do you have a mix of 2 repositories that end up being referenced:

FreeBSD-ports
vs.
FreeBSD

?

The fact that you do not show the full text of the command(s) that
produced the output leaves anyone having to guess at things. For
example, did you list -rFreeBSD-ports and -r FreeBSD explicitly on
the command line?

A similar point goes for the files: /usr/local/etc/pkg/respos/*.conf
(and /etc/pkg/*.conf if you edited anything there).

The system in question:
* runs GENERIC amd64 binaries only, no src,
* runs whatever freebsd-update fetch/install/upgrade and pkg installed
  over the years with only the 1 change described later,
but I can look up anything in particular you need.

Note: I run "pkg upgrade -f" whenever I upgrade the O/S.


> What version of pkg?
It looks like 2.4.2_1 came with 15.0-RELEASE on Dec 18.
The current version is 2.7.5.

Logs indicate the problem wasn't happening in 14.3-RELEASE-p5 GENERIC amd64 but that it began immediately upon upgrading to 15.0 when I did the "pkg upgrade -f".  That installed sndio, which got my attention because I had recently before that eliminated it.  I determined that, indeed, nothing depended on it.  "pkg autoremove" deinstalled it, along with some others:

 abseil-20250127.1
 dotconf-1.4.1_1
 ebur128-0.1.10_9
 fftw3-float-3.3.10_5
 gstreamer1-1.26.9
 libgcrypt-1.11.2
 libsamplerate-0.2.2_1
 libsoxr-0.1.3_3
 libsysinfo-0.0.3_3
 openh264-2.6.0,2
 orc-0.4.41_1
 pcaudiolib-1.2_2
 sndio-1.10.0_1
 tcl86-8.6.17
 webrtc-audio-processing-1.3_1

Those were 15 of the 17 that were perpetually installed every time I ran "pkg upgrade" anything.  Those 15 became 17 with the addition of:

 basu-0.2.1
 libxslt-1.1.45

shortly afterward.  The specific version numbers of some of those packages increased over time.  I assume the changes were to the then-current versions.

> Why do you have a mix of 2 repositories that end up being referenced:
> 
> FreeBSD-ports
> vs.
> FreeBSD
> 
> ?
It's whatever freebsd-update and/or pkg installed (ever).  I've only ever made one change, back in 2015, that didn't change the name or number of repositories.

In 2015, there was only 1 repository.  I think it was when pkgbase appeared that there started being 2 repositories that updated when I run "pkg update".  More recently, a third appeared.  Neither of the additions were my doing.

Here's what's currently in /etc/pkg/FreeBSD.conf:
==========
#
# To disable a repository, instead of modifying or removing this file,
# create a /usr/local/etc/pkg/repos/FreeBSD.conf file, e.g.:
#
#   mkdir -p /usr/local/etc/pkg/repos
#   echo "FreeBSD-ports: { enabled: no }" > /usr/local/etc/pkg/repos/FreeBSD.conf
#   echo "FreeBSD-ports-kmods: { enabled: no }" >> /usr/local/etc/pkg/repos/FreeBSD.conf
#
# Note that the FreeBSD-base repository is disabled by default.
#

FreeBSD-ports: {
  url: "pkg+https://pkg.FreeBSD.org/${ABI}/quarterly",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}
FreeBSD-ports-kmods: {
  url: "pkg+https://pkg.FreeBSD.org/${ABI}/kmods_quarterly_${VERSION_MINOR}",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}
FreeBSD-base: {
  url: "pkg+https://pkg.FreeBSD.org/${ABI}/base_release_${VERSION_MINOR}",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkgbase-${VERSION_MAJOR}",
  enabled: no
}
==========

I see the system also still has a /usr/local/etc/pkg/repos/FreeBSD.conf
file from 2015.  Here's the original FreeBSD Aug. 1, 2014 version of the file:
==========
FreeBSD: {
 url: "pkg+http://pkg.us-east.freebsd.org/${ABI}/latest",
 enabled: true,
 mirror_type: "srv"
}
==========

In 2015, I changed it to:

==========
FreeBSD: {
 url: "pkg+http://pkg.us-east.freebsd.org/${ABI}/latest",
 enabled: yes,
 signature_type: "fingerprints",
 fingerprints: "/usr/share/keys/pkg",
 mirror_type: "srv"
}
==========

I no longer recall why I needed to do that.  Wasn't my idea.  My guess is that a new version of pkg came out that required the change.  I'm happy to delete the file if that'll help.


> The fact that you do not show the full text of the command(s) that
> produced the output leaves anyone having to guess at things. For
> example, did you list -rFreeBSD-ports and -r FreeBSD explicitly on
> the command line?
No.  I would have shown those if I had.

(In reply to wbe from comment #2)

At least  some of that status looks likely to explain some
of what is happening. You may want to make a complete read
of my notes before trying anything.

> Note: I run "pkg upgrade -f" whenever I upgrade the O/S

In your specified context, that command instead tries to update
just the repositories listed that indicate "enabled: yes". In
your notes that is:

FreeBSD-ports: {
  url: "pkg+https://pkg.FreeBSD.org/${ABI}/quarterly",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}
FreeBSD-ports-kmods: {
  url: "pkg+https://pkg.FreeBSD.org/${ABI}/kmods_quarterly_${VERSION_MINOR}",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}

FreeBSD: {
 url: "pkg+http://pkg.us-east.freebsd.org/${ABI}/latest",
 enabled: yes,
 signature_type: "fingerprints",
 fingerprints: "/usr/share/keys/pkg",
 mirror_type: "srv"
}

Those are all port-package repositories (kmods being special).
It excludes FreeBSD-base (which is the FreeBSD OS pkgbase
repository as you reported the content of the files).

If you were using pkg 2.7.5, if you had used:

pkg upgrade -f -rFreeBSD-base

it would have only updated the FreeBSD OS and not have
updated the port-packages. I'm unsure if you are
intending include port-packages under your "upgrade the
O/S" wording but am guessing that you did intend to
include the FreeBSD OS. My wording will try to avoid
indicating your intended target structure.

Based on use of pkg 2.6.2, you would need to use files
to specify that you want FreeBSD-base updated, or, may
be, some others not updated in the next command(s).
Having a /usr/local/etc/pkg/repos/*.conf file with

FreeBSD-base: {
  enabled: yes
}

would then include FreeBSD-base by default.

Back to the port-package repositories . . .

The following 2 definitions conflict by, overall, using
both quarterly and latest in the command that you
typed:

FreeBSD-ports: {
  url: "pkg+https://pkg.FreeBSD.org/${ABI}/quarterly",
. . .
FreeBSD: {
 url: "pkg+http://pkg.us-east.freebsd.org/${ABI}/latest",
. . .

It looks like you will need to pkg delete the packages
that are in FreeBSD and then remove that definition before
then putting to use FreeBSD-ports (at least if you follow
modern naming conventions). I'll note that pkg delete does
not support -rFreeBSD as an option, even in 2.7.5 .

If you want FreeBSD-ports to be based on latest, then in
a /usr/local/etc/pkg/repos/*.conf file, have:

FreeBSD-ports: {
  url: "pkg+https://pkg.FreeBSD.org/${ABI}/latest",
}

and do so before updating the port-packages. You made
need to do an explicit pkg update to switch the context
after the adjustment.

If you want to update the FreeBSD OS separately from
the port-packages (for example), have
/usr/local/etc/pkg/repos/*.conf file(s) establish
"enabled: yes" vs. "enabled: no" for each repository
before running the command. Once you are using pkg
2.7.5 or later you can control the command from
options on the command line ( -rREPONAME option(s)
indicating which should be enabled ).

You may find it easier, or less confusing, to handle
just one repository at a time until the mess has been
taken care of. So multiple file adjustments as long as
pkg 2.6.2 is in use.

I'm not going to try to identify what port-packages
you want to have vs. not in the end.


Overall: I'm not seeing anything that would be fixed
in pkg itself or fixed in the pkgbase configuration
materials in the FreeBSD OS.

I'm sorry if I confused you.  The system uses freebsd-update.  It is not pkgbase'ified.  The "pkg upgrade -f" is done after all the "freebsd-update install"s and reboots have been done, to upgrade all the pkg ports (e.g., X windows).

> So multiple file adjustments as long as pkg 2.6.2 is in use.
2.6.2??  As I said in Comment 2, the system currently runs 2.7.5.

> The following 2 definitions conflict by, overall, using both quarterly and
> latest in the command that you typed:
Since the repositories have different names, pkg has been happily updating from both, sees the later version in /latest, and uses that.

> If you want FreeBSD-ports to be based on latest,
I do.

>then in a /usr/local/etc/pkg/repos/*.conf file, have:
> 
> FreeBSD-ports: {
>   url: "pkg+https://pkg.FreeBSD.org/${ABI}/latest",
> }
That looks like the better approach.  I probably need some way to remove pkg's repository information for "FreeBSD", though, or will "pkg update" discard information for repositories no longer mentioned in any of the .conf files?

> It looks like you will need to pkg delete the packages that are in FreeBSD
> and then remove that definition before then putting to use FreeBSD-ports (at
> least if you follow modern naming conventions). I'll note that pkg delete
> does not support -rFreeBSD as an option, even in 2.7.5 .
I'm not sure what you mean, but I'm not going to uninstall hundreds of currently installed pkgs, unless it's some sort of single command reinstall-like operation.  The FreeBSD /latest repo itself is (I think) larger than the FreeBSD-ports /quarterly repo in terms of number of entries.

What about using rm to delete the relevant "FreeBSD" files?  Here's what's under /var/db/pkg/ at the moment:

# ls -F /var/db/pkg
FreeBSD.meta                    repo-FreeBSD.sqlite-journal
local.sqlite                    repos/
repo-FreeBSD.sqlite             vuln.xml

# ls -F /var/db/pkg/repos/
FreeBSD/                FreeBSD-ports/
FreeBSD-kmods/          FreeBSD-ports-kmods/

Would deleting /var/db/pkg/*FreeBSD* and the directory /var/db/pkg/FreeBSD/ work?  The name local.sqlite suggests there might be references to "FreeBSD" in there somewhere that need to be cleaned up, too.

While doing all this would bring things more up-to-date, and the strategy of "fix known issues first, then see if it solves the unknown ones" is a time-honored strategy, I don't yet see how this will fix the original problem (unless the problem is something only in the FreeBSD repo data, which, I suspect, will turn out to be identical to the FreeBSD-ports /latest repo data).

(In reply to wbe from comment #4)

I understand your context little better now: I now understand
that there was no prior conversion to pkgbase so some of my
notes had no chance of being right. Sorry. I do not normally
operate based on freebsd-upgrade use for any systems.


In the original problem context, before any clean up, I would
be curious to see the output of:

# pkg which -g \*/libgcc_s.so.1

(If the system does not end up being listed, despite the
/lib/libgcc_s.so.1 , that may mean that pkg is going to
try installing/upgrading the other things it does list.)

Of course, that may not be possible now because of prior
cleanup activity.


From what you wrote, it sounds to me like you should
mostly ignore my attempted notes and go your own way.

I would suggest avoiding making pkg deal with orphaned files
from any prior activities. I would also suggest making sure
no orphaned files are left when you are done.

Also watch out for ending up with *.pgknew and/or *.pkgsave
files. (Less likely: .pkgtemp.* files.)

I'll leave it at that for more generic suggestions.

Part 1: Reply to Comment 5

# pkg which -g \*/libgcc_s.so.1
*/libgcc_s.so.1 was installed by package gcc13-13.3.0_3
*/libgcc_s.so.1 was installed by package gcc14-14.2.0_4

That makes sense: As I mentioned in the Description, gcc13 and gcc14 are installed because pkg has them as dependencies for packages I want, such as emacs (though *why* they would need gcc-anything as a dependency is still a mystery to me).

> I would suggest avoiding making pkg deal with orphaned files
> from any prior activities. I would also suggest making sure
> no orphaned files are left when you are done.
When you speak of orphaned files, are you talking about the package files as installed by pkg (the ones that "pkg which $filename" would list, like libgcc_s.so.1 above, or do you mean the /var/db/pkg/... and /var/cache/pkg/... files that might be "orphaned" by deleting the old -rFreeBSD repository description files and directories?

Part 2: GOOD NEWS!  It appears to be fixed!

I tried what you described: I changed the repo description in /usr/local/etc/pkg/repos/FreeBSD.conf from FreeBSD: to FreeBSD-ports: and used the URL from /etc/pkg/FreeBSD.conf except /latest instead of /quarterly.  No attempt to clean up anything in /var/db/pkg/.
"pkg update" said "pkg: Repository FreeBSD-ports has a wrong packagesite, need to re-create database", which it did, and now "pkg upgrade expat" offers to upgrade JUST the one file, no spurious extras!  Yay!  :-)

So, now the only issue is whether deleting the "FreeBSD"-repo-related files under /var/db/pkg/ would break something, or will pkg not care since it's no longer listed in the .conf files as a repository?

Thanks, Mark!

(In reply to wbe from comment #6)

> *why* they would need gcc-anything as a dependency is still a mystery to me

Linux tends to split the run-time libraries programs use from the
toolchain. FreeBSD ports tend not to do that. I'll use a simple
benchmark program to illustrate: benchmarks/stream . Note the path:
/usr/local/lib/gcc16/libgomp.so.1 below.

# ldd /usr/local/bin/stream_bench_omp
/usr/local/bin/stream_bench_omp:
	libgomp.so.1 => /usr/local/lib/gcc16/libgomp.so.1 (0x420f86bd0000)
	libthr.so.3 => /lib/libthr.so.3 (0x420f82a80000)
	libc.so.7 => /lib/libc.so.7 (0x420f84c00000)
	libdl.so.1 => /usr/lib/libdl.so.1 (0x420f83620000)
	libsys.so.7 => /lib/libsys.so.7 (0x420f91d70000)

Based on how the FreeBSD ports are structured, in order to have that
file present, lang/gcc16 must be installed even though the compiler
and linker and the like were only used at build time.

> When you speak of orphaned files . . .

Being more careful in my below more detailed descriptions
this time:

Orphaned files of one type are ones for which no enabled repository
for the specific command has the package that was used to do the
install/upgrade but pkg still has database records about the
install/upgrade. pkg has a means of reporting these packages that
have no "parent" (given the same set of enabled repositories for
that command as well).

Orphaned files of another type are ones where pkg has no database
record in the install/upgrade any more: those files are as if they
had been hand copied into place instead of having used pkg to get
them in place. For these pkg has no information with which to
delete the files just before installing/upgrading to the new set
of files. Such activity tends to create *.pkgsave files and/or
*.pkgnew files.

The following command will list what port packages are from
the FreeBSD repository:

# pkg query %R:%n-%v | grep ^FreeBSD:

I do not have that repository name, so an example using a
name I do have:

# pkg query %R:%n-%v | grep ^main-aarch64-default: | head
main-aarch64-default:acpica-tools-20260408
main-aarch64-default:arcanist-lib-php84-20230530
main-aarch64-default:arm-gnueabi-binutils-2.44,1
main-aarch64-default:bash-5.3.15
main-aarch64-default:binutils-2.44,1
main-aarch64-default:bonnie-2.0.6_2
main-aarch64-default:bonnie++-1.98_1
main-aarch64-default:boost-libs-1.89.0_2
main-aarch64-default:brotli-1.2.0,1
main-aarch64-default:bsdadminscripts2-0.5.1

The following is an example of then removing the repository
prefix (illustrated with mine and shortening the output with
head):

# pkg query %R:%n-%v \
| grep ^main-aarch64-default: \
| sed -e 's@^[^:]*:\(.*\)$@\1@'
| head
acpica-tools-20260408
arcanist-lib-php84-20230530
arm-gnueabi-binutils-2.44,1
bash-5.3.15
binutils-2.44,1
bonnie-2.0.6_2
bonnie++-1.98_1
boost-libs-1.89.0_2
brotli-1.2.0,1
bsdadminscripts2-0.5.1

With that information one can then force an upgrade of those
using a specific repository to do the upgrade (back to your
context):

# pkg upgrade -rFreeBSD-ports -f \
$(pkg query %R:%n-%v | grep ^FreeBSD: | sed -e 's@^[^:]*:\(.*\)$@\1@')

After that the command:

# pkg query %R:%n-%v | grep ^FreeBSD:

should generate an empty list.

At that point deletion (or disabling) of the FreeBSD
repository reference in /usr/local/etc/pkg/repos/ is
appropriate.

Then:

# pkg clean

should get back relevant space under: /var/cache/pkg/

Then you should be able to:

# rm /var/db/pkg/repos/FreeBSD /var/db/pkg/*FreeBSD.*

(In reply to Mark Millard from comment #7)

Wow, excellent!  Thanks.  Out of all the hundreds of installed packages, only 21 were not from FreeBSD:

# pkg query %R:%n-%v | grep -v FreeBSD: | wc -l
      21

and those were all from "FreeBSD-ports:".  (I was surprised the result was >1 -- the 1 being expat-2.8.2 from this morning after changing the .conf file.)

If I understand correctly, wouldn't "pkg upgrade -rFreeBSD-ports -f", without an explicit list, work, too?  It gets all the FreeBSD: ones, and upgrading the FreeBSD-ports: ones should be harmless.  Since FreeBSD: isn't even defined now, maybe I don't even need the "-rFreeBSD-ports", just another "pkg upgrade -f"?

> At that point deletion (or disabling) of the FreeBSD repository reference
> in /usr/local/etc/pkg/repos/ is appropriate.
Um, that was the change I made this morning (FreeBSD: converted to FreeBSD-ports: with /latest).  Are you saying I need to re-add the old FreeBSD: before doing the pkg upgrade in order to deal with orphaned files type 1?  The "pkg upgrade expat" this morning seemed to work fine.

Re: type 1 orphaned files:
> pkg has a means of reporting these packages that have no "parent" ...
Sounds different from the pkg query %R.  Is that something I should try first?  If so, how?

(In reply to wbe from comment #8)

My understanding is that you want to end up with FreeBSD-ports
and no FreeBSD once you are done.

My notes are based on minimizing any opportunity for
problematical interactions from the odd context: avoiding
pkg having to deal any more with any odd mix. It is up to
you what you actually do.

Note: I have a tendency to use pkg-static, which can work
in contexts where the *.so.* library status pkg needs is
messed up. Some of the below was from copied from such
material and pasted.


> Since FreeBSD: isn't even defined now, maybe I don't even need the
> "-rFreeBSD-ports", just another "pkg upgrade -f"?

In my view, you should avoid the command having more than one
repository enabled for the command. As I understand you are
using pkg 2.7.5, for which "pkg upgrade -rFreeBSD-ports -f"
guarantees that status independent of what the *.conf files
/etc/pkg/*.conf and /usr/local/etc/pkg/respos/*.conf indicate
for enabled status: least risk is to be explicit, presuming
pkg 2.7.5 is in use. (I cannot validate your environment's 
roperties.)

A possibility here for validation is to use the command:

# pkg-status repos -e

and make sure that at most one repository shows up:
FreeBSD-ports

If that is the case, lack of -rFreeBSD-ports should be fine.

If anything else also shows up, if you want to use
"pkg upgrade -f", first get to the point that only one enabled
repository shows up in the "pkg repos -e" output.


> If I understand correctly, wouldn't
> "pkg upgrade -rFreeBSD-ports -f", > without an explicit list,
> work, too?

I do not like fixing things by depending on the error/oddity
handling logic when it is reasonable to avoid such: keep the
recvery operations as simple/normal as reasonably possible.

Being explicit is less dependent on the pkg internal logic,
minimizes activity, and avoids any surprising interaction
effects --  all before the next step's:

"pkg query %R:%n-%v | grep ^FreeBSD:"

confirmation/denial of the result being an empty list.

A later "pkg upgrade" would not have an odd/messed up context
for pkg to to deal with.


As for checking for orphaned pkgs (i.e,, no repository but
still in the pkg database, not orphaned files that  no
longer have pkg database entries), here are a couple of
example ways:

pkg-static version -U -vRl\?
and:
pkg-static query '%R %n-%v' | grep ^unknown-repository

Note: That last is just a different grep than the earlier
pkg query command pipeline --and a space vs. a ":" in the
output string. Vary the strings as desired.

But the "pkg-static version -U -vRl\?" has its own advantages:
some file checking not involved in the modern package but from
prior package versions. (See below.)

As for what the "pkg-static version -U -vRl\?" looks like
(from my context):

# pkg-static version -U -vRl\?
rust-backup-librustc_driver-2bbafaf84aafced6.so-20260615105958 ?   orphaned: lang/rust-backup-librustc_driver-2bbafaf84aafced6.so

As you can see, it can report things that one is unaware
of from prior pkg activity needing to temporarily keep
available in an upgrade sequence.

Unfortunately, pkg 2.7.5 might not well identify where to
find such a file and you have to know that the file name
is after the -backup- text. So, in this case:

# find -s / -name '*-2bbafaf84aafced6.so' -print
/usr/local/lib/compat/pkg/librustc_driver-2bbafaf84aafced6.so


Those commands are deliberately looking at every enabled
repository, and should be used with all potentially in-use
repositories enabled. Any packages that are actually
installed but are from disabled repositories will report as
orphans. (Only the "pkg-static version" allows a sequence of
-rREPONAME options.)

As I understand FreeBSD-base is not potentially in use in
your environment. So it need not be enabled.