finally 2 cents of review here after a long time hiatus! thank you @des

hello folks,

ping @src

ping @src

ping

ping

In D36241#861449, @asomers wrote:

The only problem I have with this new feature is that it is 75% redundant with updatesready. I think that having two so-similar features will confuse users. Is there any way to get the benefits of both, while not adding any new commands?

any new input from @src would be really appreciated here; this is running smooth for me since past updates (for all supported releases).

In D27318#855240, @bcr wrote:

OK from manpages for these latest changes. Thanks for your patience working on this patch!

thanks @gbe !
it would be awesome to get approval from src, so we can land this one -- which I am using solo for quite a time

ping;

• manpages, @gbe @pauamma
• src, @imp @kevans

changes since last update:

1. rebased on top of freebsd/main 671f55828d03;
2. applied sugestion from @imp, to make output checks more reproducible

any new inputs about it? shall we finally land the patch?

any further suggestions or inputs about this change request? anyone?

I've being running that for quite a while and the fleet is green ever since.

hey there! hello @otis, thanks for flagging (and patching) that. much appreciated; that would speed up the fix you can commit it.

• update diff, to sync latest changes from https://reviews.freebsd.org/D36516;
• apply suggestions from @allanjude (to avoid spawn new processes, using case).

In D27318#827073, @egypcio wrote:

ping @kevans (or anyone else from src)?
mind to have a look again, to maybe approve it after all changes got applied; it should be ready-to-go.

ping?

ping?

ping @kevans (or anyone else from src)?
mind to have a look again, to maybe approve it after all changes got applied; it should be ready-to-go.

In D36241#824095, @asomers wrote:

indeed the main difference is that check only fetches a bare minimum (and sanitized) tag, which tells us which version is available on FreeBSD's update servers.

check the TEST PLAN above

updatesready do not work in that way; it downloads like all binary files and at the end report back that one is able to run e.g.: freebsd-update install.

the so-called footprint and impact coming from the "client machines" against the update servers using this proposed check command is way smaller compared to running others like install - and, IMHO, that new check command can also be used in a way to verify for available upgrades as well (again, without really fetching all required files to perform such action).

But every user who runs "freebsd-update check" will eventually also run "freebsd-update fetch". So is the overall load any less this way? Does "freebsd-update fetch" download all files on every invocation, even if there are already downloaded files that haven't been installed?

In D36241#823751, @asomers wrote:

I guess the main difference between check and updatesready is that the latter requires you to fetch the updates first, right? Is the workflow you envision a cron or periodic job that only runs freebsd-update check and informs the user if there are any updates, but makes them actually fetch those updates manually? For a user who eventually applies every update, will this new workflow result in less total load on the update servers, or about the same?

update the COMMANDS section on the manpage, to show commands sorted just like they are printed by freebsd-update -h

In D27318#821873, @des wrote:

I'm sorry, but... why? freebsd-version(1) was never intended for human consumption, it was intended for use by configure scripts, installers, etc. Adding -j was bad enough, I'm sorry I didn't catch it in time (I suppose it's too late to remove it). If you want the kind of information -v would give you, use uname instead.

update kernel_version() to support printing verbose output for different FreeBSD releases and snapshots.

adding a more detailed diff, based on git diff -U999;
getting consistent about the term "verbose output" on updated manpage.

I would need an approval from src once again (@des @gbe @kevans );
considering an implicit approval from doc - as the final diff presented here didn't touch any manpage since their last approval.

remove the number of times kernel was compiled from the verbose output of freebsd-version -kv;

this gives this output only 2 columns, instead of 3.

In D27318#821420, @kevans wrote:

Thanks!

Approved by: kevans (src)

thanks for accepting this revision @pauamma
we shall just get an OK from @gbe and/or @kevans and this is good to be committed. right?

In D27318#821022, @pi wrote:

See also PR#265789, it would help if

freebsd-version -rku and -kru did not print the same regardless of the sequence of CLI arguments.

So if some patch for that would be added to this review, that would be very helpful.

same as latest change above, removing "FreeBSD" from the output for verbose kernel's version output:

extend verbose output also into the kernel information, using what @kevans recommended for the running_version() too.

implementing suggestions from @pauamma and @kevans