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.

btw, you can try to run it with rclint, but I don't usually follow "Do not quote values unless necessary" error.

Hi, I am also working on this and didn't know this is earlier than me. I think this one is more complete while mine is only focusing on FreeBSD-base repo. However I guess there are still something useful (or not, as I'm still testing):

• bootstrap/update pkg
• only reboot when there is pkg updated

Superseded by 8e0b1a1c03a35a5db13e370cb3e62585d3db68e3

I'll bring this into the doc tree. I'll do a few minor textual fixes before committing, but nothing substantial.
Thanks for the update, it's definitely helpful to have accurate information for users on how to work with pkgbase to upgrade when 15.0 RELEASE hits.