Quote:
Originally Posted by jackie_w
If you're talking about adding a brand new patch (rather than just changing 'Enabled: no' to 'Enabled: yes'), you add the new code to the relevant .yaml file. I'm being a bit vague here because ...
I suspect many kobopatch users (not you as a first-time Kobo user) are using it in exactly the same way they used the old patching system which involved typing their same customisations to the same distributed .yaml files every time there's a firmware upgrade. This is often a lot more work than necessary.
The most convenient way to use kobopatch is by - using kobopatch.yaml as 'Mission Control' to control the enabled status of all desirable patches from a single location
- creating personal custom .yaml files to hold all your own pre-customised patches,
e.g. there would be 2 files for nickel patches - nickel.yaml (from the standard pack - never needs to be edited)
- nickel_custom.yaml (your personal pre-customised nickel patches)
Then you use kobopatch.yaml to bring it all together. The *_custom.yaml files will travel with you from firmware to firmware. Many custom nickel patches can survive across multiple firmwares. Rather fewer customised libnickel.so.1.0.0 patches survive but still quite a few. The major upgrade from fw 4.15.12920 to 4.17.13694 probably had the fewest survivors ever.
I'm sure some users have already worked all this out by reading the help notes in the distributed barebones kobopatch.yaml file, but I could do a more detailed write-up about it when I have more time to spare, i.e. probably not for a few weeks but hopefully before the next fw update. |
Thank you, I got the general picture.
