improved interoperability with app-updaters

[core-code]

this is not a bug report per-se but rather a request for an enhancement that would be in the best interest of users of apps using Squirrel.

Squirrel allows apps to implement auto-update functionality, which is great. however, some users prefer to have software that can keep all their apps up-to-date at once as this has various benefits. we are offering one of those products [1], but there are other solutions on the market, both open-source as well as commercial.

all in all, our product works great [2] and can update more than 5000 apps with the click of a button. however, there is a rare problem when our product tries to update an app, while the app also tries to update itself at the very same point-in-time using Squirrel. this can lead to failures on either end, and i guess in the absolute worst case it could even leave the user with a destroyed app. this is uncool.

this report is about preventing this problem in the interest of all users of apps with Squirrel that also use an app-updater (ours or any other).

note that we try to be /very/ careful when updating an app and we have a long array of protection-measures [e.g. we have a good look if the 'ShipIt' process inside the app-bundle is running] and sanity-checking but our logfiles still indicate that some updates fail because a concurrent update has been performed.

this issue happens especially because Squirrel will update apps transparently without asking the user - after the app has quit. when a user asks our app to update an app our app will ask the app-to-be-updated to quit, in order update it - but this is exactly the time when your transparent update-at-quit code kicks in: perfect collision course. we should avoid problems here.

long story short we'd like to prose a solution to avoid any app-updater trying to update an app at the very same time as it also tries to update itself. i imagine a solution has two parts: 1.) a way for Squirrel to tell the outside world that it is going to update the host app. if this 'flag' is set then no outside app-updater should try to update this app 2.) a way for app-updaters to tell Squirrel not to update its host app because an update is already being performed by the app-updater so, whoever comes first "wins" and should continue doing the update without having to fear that the other party will do it at the same time. basically we need a mutex/lock for app-updates.

implementing a completely safe/atomic IPC lock is probably hard and/or overkill but even a simple implementation could greatly help to prevent the discussed problem.

i haven't put too much thought into it since i want to hear your preferences here first but i suppose we could use either a lockfile or NSDistributedNotification's for this. a lockfile is probably better, unless the 'sandbox' comes into play but i am not sure how many of apps using Squirrel are sandboxed.

we realise that while you may want to see this issue fixed in the interest of users of apps using Squirrel you may not want to put a lot of effort into it yourself. so, we are fully prepared to implement a solution and contribute it to your project. the only thing we would need is 1.) a confirmation beforehand that the contribution will be accepted into Squirrel 2.) some guideline how a solution needs to look to be acceptable 3.) maybe some small pointers where/how best to implement it :)

[1] https://www.corecode.io/macupdater/index.html [2] which is a totally unbiased statement

[core-code]

note that this also affects the other popular Mac self-update library. i've sent a report to them https://github.com/sparkle-project/Sparkle/issues/1568. it would be great if we could solve this situation with a common mechanism to both Sparkle and Squirrel, but we'd have no problem with two distinct solutions either.

[anaisbetts]

I think that if you see Squirrel as a framework, you should simply not touch this app. Why do users need two updaters for their app?

[core-code]

@anaisbetts thanks for your answer, but ... ugh.

I think that if you see Squirrel as a framework, you should simply not touch this app.

this is not an option. we'd have to remove support for automatically updating thousands of apps. our users would hate that.

Why do users need two updaters for their app?

huh - why do humans use computers instead of enjoying nature and live in the forest - wouldn't this solve millions of problems in an instant? i find this attitude very weird.

the fact is that people love app-updaters and just because you don't seem to have a use for them personally does not mean they don't serve a very useful function and are in widespread use.

i think we we should constructively strive for a solution here instead of dismissing the problem. i already said that we are prepared to do all the coding so it is not like i make some demands for someone else to work on this.

note that i got a constructive and professional response to the same problem over at Sparkle ( https://github.com/sparkle-project/Sparkle/issues/1568 ).

[anaisbetts]

You should take this up with individual app developers, it is not Appropriate to try to change the update policy of other developers' apps via rigging the underlying updater behind their back. At the end of the day, Squirrel is a library that developers use to implement their update policy - they are the ones that get to choose that policy, not us.

[core-code]

You should take this up with individual app developers,

are you honestly suggesting we contact more than 1000 app vendors shipping Mac apps that use 'Squirrel' individually about fixing an issue that could be trivially fixed by just making trivial adjustments within Squirrel itself?

it is not Appropriate to try to change the update policy of other developers' apps via rigging the underlying updater behind their back

i did not suggest 'rigging' of any kind.

Squirrel is a library that developers use to implement their update policy -

i know it is a library, this is exactly why i suggested fixing an issue that affects /all/ apps using Squirrel at the library level.

they are the ones that get to choose that policy, not u

no, at the end of the day it is the users get to choose the update policy. if users choose to use app-updaters, then this choice should be accommodated to make that work well. you do care about users, do you?

if what you are trying to say is 'some app vendors may not like app-updaters updating their apps', then i suggest working together on solving the issue i mentioned while also introducing a new flag 'no app-updaters please'. i am not sure why any vendor would want to disrespect the wishes of their users in such a unkind way, but if such a flag existed it would help making sure your concern regarding this is accommodated. which, for reference, is currently not the case /hint, hint/.