cpu-microcode-intel: Add knobs for RC RUN_DEPENDS and split files

[marius]

Summary

Split UCODE files as well as dependency on sysutils/cpu-microcode-rc
are only required for use with cpucontrol(8) and update method two
respectively. The first method needs neither so we can spare a few
MiB and a superfluous port.

[jrm]

sysutils/cpu-microcode-intel/Makefile

22

Should we merge this into one option? In other words, is there a case when a user would want the RC script but not the split microcode files required for cpucontrol(8), or would a user want the split microcode files but not the RC script that calls cpucontrol(8)?

I have this change and a few others in a working branch. It's probably easier for me to either update this review or create another if that's alright with you.

[jrm]

sysutils/cpu-microcode-intel/Makefile

22

I didn't want to update here without permission, so I put some proposed tweaks on GitHub.

https://github.com/freebsd/freebsd-ports/compare/main...Jehops:freebsd-ports:arcpatch-D41904?expand=1

[marius]

sysutils/cpu-microcode-intel/Makefile

22

Yes, having split UCODE files is useful for testing purposes as a developer as well as for a user when required to update UCODE without a reboot but otherwise rely on the loader method during boot. Neither scenario requires the RC script, though. When adding two separate knobs I was also thinking long-term. Since the advent of the superior boot loader updating approach, I no longer see a reason for performing automatic updates via the RC script. Thus, the latter should be deprecated (or rather shouldn't have been brought over to cpu-microcode-intel in the first place) by defaulting it to off later and eventually removing the option. At that point, the split files still will be useful in the aforementioned scenarios, though.

However, you have a point in that the inverse makes no sense, i. e. depending on the RC script but not installing the split UCODE files. I'll add an RC_IMPLIES=SPLIT.

Regarding your other suggested changes as far as I can spot them:
o According to my reading of the Porter's Handbook, bumping PORTREVISION is required when the package content of either the default build or existing non-standard build option changes. However, - as in this case - I don't see where the Handbook requires a bump for a newly introduced build option. That also wouldn't make sense since a user needs to manually set the newly added knob to a non-default setting, rebuild and install the port anyway. I won't argue strongly against a bump, though, given it's generally a cheap thing to do.
o I tried with SPLIT_VARS_OFF=NO_BUILD=yes and that didn't work as expected. I'll re-test, though, in case that was due to a typo, wrong spot in the Makefile or something like that. However, that's mainly a matter of taste, anyway.

[marius]

PORTVERSION bump and style changes suggested by jrm@, added RC_IMPLIES=SPLIT

[jrm]

Sorry for the delay. Looks good to me.

I spoke to @seanc about the cpu-microcode ports and will take maintainership but will wait for you to commit so you don't have to deal with a conflict.

[jrm]

In D41904#970117, @jrm wrote:

Sorry for the delay. Looks good to me.

I spoke to @seanc about the cpu-microcode ports and will take maintainership but will wait for you to commit so you don't have to deal with a conflict.

I meant @sbruno, the maintainer, not @seanc.