Right, I forgot about plugintype. You do have a step to enable it - I think it needs to be dropped then.
Then the only step it would replace is UUID generation with UUIDgen - I use a Python library to do the same.
I appreciate your thought-out proposal, thanks a lot for looking into this and I'm excited to contribute.
- Editing the existing Clover/config.plist wouldn't be hard to implement, my concern is that modifying system partition will require more QC and support, because the script would be able to brick the computer if something goes wrong during the execution. Even with a perfectly valid script there are ways this can go wrong, e.g. a power outage. Editing or creating the config during initial build would be safer, because you'll still need to use Clover configurator after and that'll validate the changes done by the script. Even if something goes very wrong - worst thing that'll happen is that installation USB will be unbootable. I'm sure ups wouldn't appreciate some users in this thread complaining about bricking their computer
- I agree that indeed changes in source config.plist would need to be synched-up to this project, this creates maintenance overhead. It's much smaller than supporting editing of unique configs users have already put on their EFI Partition, but still existent. Right now I have a template in there that I created manually, and that would need to be changed. A few approaches we can do to eliminate the overhead:
1) Remove the config.plist from your EFI distribution, so that the original source of truth is stored alongside this script. Probably not the best approach.
2) We can modify the script to replace config supplied in your EFI distribution with the one rendered from template (but the overhead will stay)
3) We can implement an option to modify the config supplied using XML replacement, so that Cloverfield is not bundled with a config.plist at all
+ For 2) and 3) we can actually implement a download of the most recent EFI distribution to make it easier to the users.
++ I could also add a feature to drop in appropriate SMC Kext pre-modified with the right number of cores
+++ If this happens to run on the target machine (e.g. under Windows and Linux) - it would be easy enough to auto-detect the CPU and make the script completely automatic.
Question: do you expect people will want to apply CPU replacements after initial build is done? My understanding is that this only has to be done once per build.
Let me know what I'm missing!
, 
