in ports is going to move to shlibs as well, this is wip, this is doable since pkg 2.8 for a reason independant from what we are discussing here.

In D58339#1387759, @vladlen wrote:

Could you give me just an idea of the reason why we don't use dependencies for pkgbase packages?

It is for demonstration of dependencies. Really most of the pkgbase packages depend on 3 library:

• utilities
• runtime
• clibs

And these library has depenencies, that could be entered one time. This image for demonstarion of all dependencies from these libraries (red - existed, but not detected dependencies: wrong dependency in Makefile or dependency in script):
{F175241070}

In D58339#1386633, @bapt wrote:

does this case still happen in 2.8.4 ? if yes it mans I need to release 2.9

In D58339#1387376, @ivy wrote:

ld-elf.so.1: /usr/sbin/certctl: Undefined symbol "fts_open@FBSD_1.9"

this is because it's trying to install certctl and run its post-installed script before the library it depends on, which i think is a known issue in pkg. but it *does* eventually install all the required new packages, right?

we should fix this, but i don't think adding explicit depends will help (or even if it does, it's not the right approach).

this is a pkg bug I will try to reproduce next week with 2.9

yes clibs should be the first one upgraded

[143/228] Upgrading FreeBSD-caroot from 15.1 to 16.snap20260720181726...
[143/228] Extracting FreeBSD-caroot-16.snap20260720181726: 100%
ld-elf.so.1: /usr/sbin/certctl: Undefined symbol "fts_open@FBSD_1.9"
pkg: POST-INSTALL script failed
[144/228] Upgrading FreeBSD-clibs from 15.1p4 to 16.snap20261007175931...
[144/228] Extracting FreeBSD-clibs-16.snap20261007175931: 100%

ld-elf.so.1: /usr/sbin/certctl: Undefined symbol "fts_open@FBSD_1.9"

In D58339#1386633, @bapt wrote:

does this case still happen in 2.8.4 ? if yes it mans I need to release 2.9

does this case still happen in 2.8.4 ? if yes it mans I need to release 2.9

In D58339#1349105, @vladlen wrote:

The reason is fundamental: it is technically impossible for pkg to know which package provides a required library in the new release

In D58339#1343137, @ivy wrote:

I don't believe this is a bug in pkg(8). I reviewed a very long log file (with -dddd) and confirmed that library dependencies are not used during the scheduling stage.

that's the bug: a package's dependencies should be installed before the package itself. there's no reason for this to be different with shlib dependencies, especially since that will break many/most post-install scripts.

I don't believe this is a bug in pkg(8). I reviewed a very long log file (with -dddd) and confirmed that library dependencies are not used during the scheduling stage.

In D58339#1341688, @ivy wrote:

we don't want to add manual dependencies on library packages; these are supposed to be handled automatically by pkg. if that's not working properly, it's a bug in pkg(8) and should be fixed there.

we don't want to add manual dependencies on library packages; these are supposed to be handled automatically by pkg. if that's not working properly, it's a bug in pkg(8) and should be fixed there.

Remove unintentionally included failsafe handling

LGTM!

fix comment typos, thanks @cperciva!

implement cperciva/lwhsu sha256 suggestion, thanks guys!

In D56381#1302616, @bapt wrote:

In D56381#1302615, @cperciva wrote:

Fair point, but I'm a little bit concerned about this being brittle -- /var/db/pkg/local.sqlite is not a public interface for pkg, so there's no guarantee that a future pkg won't (a) change that path, or (b) touch that file even if nothing has changed. I don't want to suddenly discover in FreeBSD 16.3 that VMs aren't rebooting after applying security updates because something changed in pkg.

that is a valid concern from @cperciva I don't think I will change anything in that area, but yes the content of /var/db/pkg is supposed to be opaque. (I know I am the one who recommended the mtime check in the first place).

In D56381#1302615, @cperciva wrote:

In D56381#1302566, @ziaee wrote:

In D56381#1302390, @cperciva wrote:

In D56381#1302386, @ziaee wrote:

ok, what if we separate the pkg update, and take the state after updating, but before upgrading, then we will actually know if the upgrade did anything. maybe because of this we can simplify the logic at the end a bit more.

I think pkg info | sha256 would work? If any packages are updated (or installed or removed) then that hash will change.

I think it would work too, but I don't see why we wouldn't want to stat the mtime in between updating and upgrading instead. By my rough estimate, time(1) shows 0.08 real for the pkg info | sha256, but for stat -f %c /var/db/pkg/local.sqlite it shows 0.00 real, so, that's less electricity, right?

Fair point, but I'm a little bit concerned about this being brittle -- /var/db/pkg/local.sqlite is not a public interface for pkg, so there's no guarantee that a future pkg won't (a) change that path, or (b) touch that file even if nothing has changed. I don't want to suddenly discover in FreeBSD 16.3 that VMs aren't rebooting after applying security updates because something changed in pkg.

In D56381#1302566, @ziaee wrote:

In D56381#1302390, @cperciva wrote:

In D56381#1302386, @ziaee wrote:

ok, what if we separate the pkg update, and take the state after updating, but before upgrading, then we will actually know if the upgrade did anything. maybe because of this we can simplify the logic at the end a bit more.

I think pkg info | sha256 would work? If any packages are updated (or installed or removed) then that hash will change.

I think it would work too, but I don't see why we wouldn't want to stat the mtime in between updating and upgrading instead. By my rough estimate, time(1) shows 0.08 real for the pkg info | sha256, but for stat -f %c /var/db/pkg/local.sqlite it shows 0.00 real, so, that's less electricity, right?

In D56381#1302390, @cperciva wrote:

In D56381#1302386, @ziaee wrote:

ok, what if we separate the pkg update, and take the state after updating, but before upgrading, then we will actually know if the upgrade did anything. maybe because of this we can simplify the logic at the end a bit more.

I think pkg info | sha256 would work? If any packages are updated (or installed or removed) then that hash will change.

In D56381#1302386, @ziaee wrote:

ok, what if we separate the pkg update, and take the state after updating, but before upgrading, then we will actually know if the upgrade did anything. maybe because of this we can simplify the logic at the end a bit more.

ok, what if we separate the pkg update, and take the state after updating, but before upgrading, then we will actually know if the upgrade did anything. maybe because of this we can simplify the logic at the end a bit more.

greatly simplify based on cperciva feedback.

I'm inclined to skip the "figure out if we need to reboot or just restart services" complexity at this point because

incorperate suggestions by @bapt. Do not reboot unless kernel is updated. In all other situations, including situations where only the pkg database is updated, just restart all services.

In D56381#1295504, @ziaee wrote:

note, i like a blank line at the end of scripts for cat reasons. if we don't want this, i can remove it, but it doesn't hurt anything and we do it all over the place.

In D56381#1295529, @ziaee wrote:

use logic inspired from @lwhsu to prevent reboot if nothing happened. compare the file size in bytes of the pkg database instead of using pkg inf and checksum to save water/coal. tested on my laptop

In D56381#1295532, @ivy wrote:

@lwhsu out of interest, how do you end up with a system that has FreeBSD-base packages installed but doesn't have pkg bootstrapped?

@lwhsu out of interest, how do you end up with a system that has FreeBSD-base packages installed but doesn't have pkg bootstrapped?

use logic inspired from @lwhsu to prevent reboot if nothing happened. compare the file size in bytes of the pkg database instead of using pkg inf and checksum to save water/coal. tested on my laptop

implement bootstrap pkg if it is not done so already, based on lwhsu feedback, thanks! note, i like a blank line at the end of scripts for cat reasons. if we don't want this, i can remove it, but it doesn't hurt anything and we do it all over the place.