[Magisk] pndwal:
But unless I'm missing something, this is really the ROMs inbuilt restore-after-update (addon.d in A-only, add-on.d-v2 for A/B) support... Doesn't addon.d.sh just tell the ROM installer package how to re-flash Magisk after update is installed?...

I believe it's alao implemented both for direct recovery custom ROM flashing and for system OTA update engine in the case of A/B / add-on.d V2...

... You may be right, but would it hurt if those using module have it checking for system/addon.d and ensuring the .sh file exists on booting?... And after one boot users could also disable this module and Magisk would still be preserved w/ next ROM flash...

I think only Magisk survival would be broken... addon.d would still check and store GApps configuration, uninstall GApps, flash ROM, then restore GApps w/ previous configuration successfully for example (if I'm not mistaken).

But the module is just to write survival script for ROM installer to use... No need for running module... If script is already in /system (or some new accessible location as was discussed) addon.d survival should work... Magisk daemon is never running during ROM flashing directly from recovery anyway, and addon.d works for this as well as OTA engine supported A/B updates AFAIK...

I think the main issue has largely been the dismissive / uncaring tone /attitude toward all the work put into this (old) Magisk survival method... It was hard to watch and clearly hurtful, but there is a case for this as I see it... It just didn't need to be presented so harshly...

That issue has remained for nearly 2 years, and it's largely to make the case for addon.d being added where system remains writable for custom ROMs w/ Magisk App patching / flashing method... It is only applied when using .zip installer currently and TJW has so far not wanted to add this for new fully supported App installation method... Making addon.d work with script in some other location has also been mooted...

Writing to /system is understandably becoming something it's desirable to avoid, and may be fraught even for custom ROMs... Magisk cannot detect if a future ROM update will support addon.d either, so Magisk simply patches /system if it's possible accoss the board...

Using a module at least makes this a user choice... /system will never be written to without a user installing a module to do it..

Install method parity also means users won't be surprised when App-install method doesn't preserve Magisk thru custom ROM installs that support addon.d...

It also seems clear John himself is reluctant to add this function to Magisk installed via App, so a module would mean custom ROM users get this option with proper App installation methods immediately, and it would properly close this GitHub issue which has made no real progress in 2 years... I think that that is a common aim at least...

Also, it seems to me that this is just a simple repackaging of the install script... All @osm0sis' hard work, coding, and collaborative efforts with LineageOS etc can remain... Essentially code in addon.d.sh itself can remain intact / as-is, as can the addon.d 'engine' in ROM installers...

Certainly with you there...

Initially Shana simply said she intends to remove addon.d support for 'feature parity'...

Harsh!...

A fight seems to be needed to ensure custom ROM users can have an acceptable alternative form of addon.d based Magisk survival... So far the fight seems to be producing this... 🙃 PW