I will be testing this for Mac OS.

This will NOT remove files in the system library as this is "offlimit" for scripts.
Files should not be in there anyway.

This will NOT remove files in the system library as this is "offlimit" for scripts. Files should not be in there anyway.

So why does it even try?

Who has a problem with this?
1% of our users?
Can't they just learn how to read?

This will NOT remove files in the system library as this is "offlimit" for scripts. Files should not be in there anyway.

So why does it even try?

Couple things there :

• The script will not be able to access the systems Application Support folder by default. (No access unless ran as admin or root or else

• But, if users ended up with files there this means the script should also have access. )I could not fully test that..

You review is important, we could only target the OBS-ndi files in the user ~/Library.

Note that there is another PR adding the path of the detected OBS-ndi that should help most requests.

This was the main source for support requests coming in the last weeks as in "I followed the install instructions but it still says it's there".

Understood. Just seems like a lot of work for "a few" users.

Still, it is nice to have I guess. I just wouldn't want it to cause more problems than it is trying to fix.

I wouldn't want it to fix a problem for 3 users [that can't/won't read/follow directions] but cause a problem for hundreds.

I would still like to move the postinstall script from the generic [all platforms] build-aux to cmake/macos/resources [macos specific]

@BitRate27 I see that the postinstall & script folder is not being deleted after distroav install.

I am not keen on creating garbage files, we should revisit this approach.

Thanks! Will not be able to look at this until Dec 2.