[Bug 296467] pkg upgrade installs unrelated, unnecessary other packages

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=296467

--- Comment #9 from Mark Millard <marklmi26-fbsd@yahoo.com> ---
(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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.