<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
try this recipe:<br>
<br>
<!-- check the version no. to check the package state --><br>
<check type="logical" condition="or"><br>
<check type="uninstall" condition="versiongreaterorequal"
path="Google Chrome" value="%version%" /><br>
<check type="file" condition="versiongreaterorequal"
path="%PKG_DESTINATION%\chrome.exe" value="%version%" /><br>
<check type="file" condition="versiongreaterorequal"
path="%PKG_DESTINATION%\new_chrome.exe" value="%version%" /><br>
<check type="file" condition="versiongreaterorequal"
path="%PKG_DESTINATION(x86)%\chrome.exe" value="%version%" /><br>
<check type="file" condition="versiongreaterorequal"
path="%PKG_DESTINATION(x86)%\new_chrome.exe" value="%version%" /><br>
</check> <br>
<br>
Chrome seems to be unique in that the developers actually put some
thought into handling updates while the main program is running.<br>
If Chrome is running, then Chrome installs to new_chrome<br>
When the last instance of Chrome exits, the files are renamed
(somehow) so that the new_chrome becomes the installed version.<br>
I wonder (never checked) if the installed version number also only
gets updated at this time so your 20% of failures are because Chrome
is still running.<br>
Regardless, the code above should solve your issues.<br>
<pre class="moz-signature" cols="72">--------------------------------------------------------------
Dave Evans</pre>
<div class="moz-cite-prefix">On 06/10/2020 21:06, <a class="moz-txt-link-abbreviated" href="mailto:cleitet@gmail.com">cleitet@gmail.com</a>
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAMnHmWP30QAM3Kr0e+3Fg5W-KFwrfg8pHyvYCNgj3ePah9iekw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">Try to do a version check on the exe file instead
of what's written to the add/remove programs entry. <a
href="https://wpkg.org/Packages.xml#File"
moz-do-not-send="true">https://wpkg.org/Packages.xml#File</a> has
some documentation on how to do that.</div>
<div dir="ltr"><br>
</div>
<div>-CL</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">man. 24. aug. 2020 kl. 16:03
skrev Steve Kersley <<a
href="mailto:steve.kersley@keble.ox.ac.uk" target="_blank"
moz-do-not-send="true">steve.kersley@keble.ox.ac.uk</a>>:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-GB">
<div>
<p class="MsoNormal">Does anyone have a decent way to
create a package for Google Chrome that works reliably?</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Being a simple MSI, it should be
straightforward. But our finding is that some of the
time, in an inconsistent and unpredictable way, the
enterprise version of Chrome sometimes installs itself
with the MSI version number rather than the Chrome
version number (from the current version: ’68.12.49287’
vs ’84.0.4147.135’). Obviously this triggers wpkg to
think there’s a new version when there isn’t as the
versions don’t match. The installer itself knows not to
update which doesn’t clear the problem – the version
number showing in Add/Remove remains the MSI version
until the next update. If it was consistently one way
or the other, it would be trivial. But I’d estimate it
gets it right about 80% of the time. There’s been an
open issue on the Chromium issue tracker about it doing
this for 10 years with still no fix, or even
acknowledgement that there’s a problem to fix:
<a
href="https://bugs.chromium.org/p/chromium/issues/detail?id=67348"
target="_blank" moz-do-not-send="true">https://bugs.chromium.org/p/chromium/issues/detail?id=67348</a></p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">In normal circumstances, I would (and
have done for some time) just leave it, it doesn’t cause
any harm to have it try to reinstall Chrome. But in
these strange times, I have a lot of staff remote
working via remote desktop, and they are reluctant to
reboot their PCs remotely at the end of the day. As a
result I’ve been trialling ‘sonicnkt’s fork of wpkg-gp
plus the system tray client that notifies of pending
updates, and the problem now is that when Chrome has
installed itself like this, the tray tool pops up an
update notification every 30m or so, for an update that
simply won’t go away.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Steve.</p>
</div>
</div>
---------------------------------<br>
wpkg-users mailing list archives >> <a
href="http://lists.wpkg.org/pipermail/wpkg-users/"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.wpkg.org/pipermail/wpkg-users/</a><br>
_______________________________________________<br>
wpkg-users mailing list<br>
<a href="mailto:wpkg-users@lists.wpkg.org" target="_blank"
moz-do-not-send="true">wpkg-users@lists.wpkg.org</a><br>
<a href="https://lists.wpkg.org/mailman/listinfo/wpkg-users"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.wpkg.org/mailman/listinfo/wpkg-users</a><br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">---------------------------------
wpkg-users mailing list archives >> <a class="moz-txt-link-freetext" href="http://lists.wpkg.org/pipermail/wpkg-users/">http://lists.wpkg.org/pipermail/wpkg-users/</a>
_______________________________________________
wpkg-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:wpkg-users@lists.wpkg.org">wpkg-users@lists.wpkg.org</a>
<a class="moz-txt-link-freetext" href="https://lists.wpkg.org/mailman/listinfo/wpkg-users">https://lists.wpkg.org/mailman/listinfo/wpkg-users</a>
</pre>
</blockquote>
<br>
</body>
</html>