[leonardder]

On the other hand, the original idea of having the flag be a dummy addon was to have it be outside the addon. This would allow the maintainer of the build to drop new versions in without having to modify anything. So perhaps the enable flag could still be external to the addon. And it doesn't have to be a dummy addon, it just needs to be in a place the addon can reliably find it no matter what platform it's installed on.

As a package maintainer, it is perfectly possible to add a package specific file with a flag to the addons directory. I don't get entirely why that file should be outside of the addons structure for that.

I may be missing something but what I meant was, if the flag is in the addon (ie. somewhere in the service.xbmc.tts directory) then when you replace that directory you have to re-add that flag. If it is outside that directory, this would not be necessary.

The current process for package building for OSMC is as follows in a build shell script:

1. download the addon source
2. extract it to files/usr/share/kodi/addons/service.xbmc.tts
3. Run dpkg_build files/ package.deb

So, it is as simple as inserting a step after 2, echo "something" > files/usr/share/kodi/addons/service.xbmc.tts/file. Than, the file with the flag is packaged with the addon. When a new version is installed using a replaced package, that package will also contain the new flag. When someone deletes the package, the flag also is removed from the system.

Only thing I do not yet know which might object this above point is when kodi updates the addon. I don't know whether kodi is allowed to update addons in the special??xbmc folder. If so, does it replace the service.xbmc.tts folder entirely?