After pkgbase upgrade from 15.0 to 15.1 - orphaned base packages

dvl@

dvl@

Developer
One of my regular Nagios checks is for orphaned packages. I find that an essential check. If the package is not available, that might be something to investigate. FYI, the check is pkg version -vRL= | grep orphaned

On about half the hosts I have updated, I see this output (the other hosts have nil output for that command):

Code: 
[12:15 r730-01 dvl ~] % pkg version -vRL= | grep orphaned
FreeBSD-kerberos-lib-backup-libkrb5profile.so.122-20260717191016 ?   orphaned: base/FreeBSD-kerberos-lib-backup-libkrb5profile.so.122
FreeBSD-lldb-backup-libprivatelldb.so.19-20260717191013 ?   orphaned: base/FreeBSD-lldb-backup-libprivatelldb.so.19
FreeBSD-runtime-backup-libpam.so.6-20260717191009 ?   orphaned: base/FreeBSD-runtime-backup-libpam.so.6
FreeBSD-runtime-backup-libprivatezstd.so.5-20260717191009 ?   orphaned: base/FreeBSD-runtime-backup-libprivatezstd.so.5

The list is the same on all afflicted hosts, the timestamp portion of the package name differs, but the origins are identical.

What's up?
 
dch asked if I had this entry:

Code: 
[15:48 r730-01 dvl ~] % grep BACKUP_LIBRARIES /usr/local/etc/pkg.conf
BACKUP_LIBRARIES=yes

* Every host with the orphaned packages has this entry.
* Every host without orphaned packages does not have that entry.
 
I guess a question I have is "what exactly does orphaned" mean in this context?
Reason for asking is I just did that command on a 15.1 system (that had been upgraded from 15.0) and have about 42 orphaned packages, the bulk of them "py311"
pkg autoremove shows nothing so orphaned seems to not be related.
 
mer said:
I guess a question I have is "what exactly does orphaned" mean in this context?
Click to expand...
The package is not available in the package repo.

mer said:
Reason for asking is I just did that command on a 15.1 system (that had been upgraded from 15.0) and have about 42 orphaned packages, the bulk of them "py311"
pkg autoremove shows nothing so orphaned seems to not be related.
Click to expand...
Those py311 packages may have been replaced by py312 (or later) packages. You might also have two versions of python installed now.
 
dvl@ said:
The package is not available in the package repo.


Those py311 packages may have been replaced by py312 (or later) packages. You might also have two versions of python installed now.
Click to expand...
Thanks; that all makes sense.
I'm guessing that for my py311 packages if a "pkg info -r py311-ABCD" shows nothing or only another py311 package it can be removed.
I would start to argue that perhaps pkg autoremove should detect that condition :)
 
mer said:
Thanks; that all makes sense.
I'm guessing that for my py311 packages if a "pkg info -r py311-ABCD" shows nothing or only another py311 package it can be removed.
I would start to argue that perhaps pkg autoremove should detect that condition :)
Click to expand...
The way I do it:

  1. is the newer python package installed, yes, OK, ignore, no, look closer (like your `pkg -r` line of inquiry)
  2. two Pythons installed? Remove the old one. Look at what else gets removed
I think you can jump straight to step 2 because that will show you the list of packages to be removed before removing them. Only py311? Good to go.
 
  • Like
Reactions: mer
Thanks. Digging in more on my specific, looks like 15.1 has python 3.12 as default, I only have python 3.11 installed so I need to update the local installed packages to use python 3.12. I recall doing this when python 3.11 because the default, I just need to dig out the commands.
Oh, nice post about updating using pkgbase on your other diary.
 
dvl@ said:
One of my regular Nagios checks is for orphaned packages. I find that an essential check. If the package is not available, that might be something to investigate. FYI, the check is pkg version -vRL= | grep orphaned

On about half the hosts I have updated, I see this output (the other hosts have nil output for that command):

Code: 
[12:15 r730-01 dvl ~] % pkg version -vRL= | grep orphaned
FreeBSD-kerberos-lib-backup-libkrb5profile.so.122-20260717191016 ?   orphaned: base/FreeBSD-kerberos-lib-backup-libkrb5profile.so.122
FreeBSD-lldb-backup-libprivatelldb.so.19-20260717191013 ?   orphaned: base/FreeBSD-lldb-backup-libprivatelldb.so.19
FreeBSD-runtime-backup-libpam.so.6-20260717191009 ?   orphaned: base/FreeBSD-runtime-backup-libpam.so.6
FreeBSD-runtime-backup-libprivatezstd.so.5-20260717191009 ?   orphaned: base/FreeBSD-runtime-backup-libprivatezstd.so.5

The list is the same on all afflicted hosts, the timestamp portion of the package name differs, but the origins are identical.

What's up?
Click to expand...
Same here:
Code: 
 ~ > pkg version -vRL=                          
Updating FreeBSD-ports repository catalogue...
FreeBSD-ports repository is up to date.
Updating FreeBSD-ports-kmods repository catalogue...
FreeBSD-ports-kmods repository is up to date.
Updating FreeBSD-base repository catalogue...
FreeBSD-base repository is up to date.
All repositories are up to date.
FreeBSD-kerberos-lib-backup-libkrb5profile.so.122-20260720180304 ?   orphaned: base/FreeBSD-kerberos-lib-backup-libkrb5profile.so.122
FreeBSD-lldb-backup-libprivatelldb.so.19-20260720180302 ?   orphaned: base/FreeBSD-lldb-backup-libprivatelldb.so.19
FreeBSD-runtime-backup-libpam.so.6-20260720180301 ?   orphaned: base/FreeBSD-runtime-backup-libpam.so.6
FreeBSD-runtime-backup-libprivatezstd.so.5-20260720180301 ?   orphaned: base/FreeBSD-runtime-backup-libprivatezstd.so.5
 ~ >
 ~ > pkg check -da
Checking all packages: 100%

From the pkg.conf man page:
BACKUP_LIBRARIES: boolean
If set to true and if an upgrade will remove a library
(typically due to the library version number having been
bumped), then pkg(8) will back up the library to the path
defined by BACKUP_LIBRARY_PATH. A package containing the
backed up library will be created. This package is named
after the original package containing the library, with
the suffix `-backup-libraries' appended. The package ver-
sion will be bumped whenever an additional library is
backed up. Default: NO.
Click to expand...

I did my upgrade this week, for now I prefer to not touch those backup libs, I don't know if pkgpase is suppose to fix this by itself or not.
 
mer said:
Thanks. Digging in more on my specific, looks like 15.1 has python 3.12 as default, I only have python 3.11 installed so I need to update the local installed packages to use python 3.12. I recall doing this when python 3.11 because the default, I just need to dig out the commands.
Oh, nice post about updating using pkgbase on your other diary.
Click to expand...
"pkg set -p -n py311-:py312- && pkg upgrade". This may fail if you have a mix of 311 and 312 pkgs and will require a few iterations (including using "pkg check -d" etc.). But you should really keep an eye on /usr/ports/UPDATING!
 
bakul said:
"pkg set -p -n py311-:py312- && pkg upgrade". This may fail if you have a mix of 311 and 312 pkgs and will require a few iterations (including using "pkg check -d" etc.). But you should really keep an eye on /usr/ports/UPDATING!
Click to expand...
Thanks. I found a post from SirDice with same info and yes I should pay a bit more attention to "UPDATING".
 
You must log in or register to reply here.
Back
Top