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.

committed

looks good to me

I don't understand the point of merging both version why not only the latest ?

note I proposed to import pkgconf back in 2012: https://lists.freebsd.org/pipermail/freebsd-hackers/2012-December/041471.html and this lead to some discussions.

nuageinit is not impacted as it only parses json with libucl
I agree we should anyway land this

this look good to me