[wpkg-users] Old version reinstall - WPKG is nice but it still needs improve

[Falko Trojahn]

Hallo Rainer,

thanx for your quick and detailed answer.

> Falko Trojahn wrote:
>> Firefox updated itself, e.g. to Revision 2.0.0.13. Next time Wpkg
>> starts,
>> the uninstall check looks for 2.0.0.12 (which of course is missing then)
>> and
>> reinstalls the old version, until the xml on the server is updated, too.
>
> This is true - but non-admin users cannot do the auto-update (most users
> should be non-administrators). This is exactly the intended behavior.
Yes, but sometimes we have applications, you know, only working with
administrator rights ...

> The Administrator decides which version is to be installed. As long as
> 2.0.0.12 is the supported version it should be installed (and not
> another one). In case the administrator decides that 2.0.0.13 is allowed
> as well (but not distributed) he might just extend the package check and
> add 2.0.0.13 version as valid as well (even without actually installing
> it).
>
>
>> If I remember right, this hasn't been so with 0.9.x versions of wpkg.
>
> This I don't know - but if it was like this, then I would consider it as
> a bug. Leaving 2.0.0.13 installed (while 2.0.0.12 is actually not
> installed any more) is not the intention of a system administrator.
>
>
>> So, setting 'execute="once"' in the firefox packages would prevent this?
>
> Yes, in this case the check will not be done on each synchronization. So
> no matter if the user removes or upgrades the supported version WPKG
> will not take any action (just assuming 2.0.0.12 is still in place).
>
> NOTE: WPKG will also not re-install in case the user removes FF
> completely.
Yes, this is the main problem in this case.

>
>
>> Other possibilities I could imagine are:
>> - disable autoupdate in prefs.js (which I won't prefer for security
>> reasons)
>
> Why not? The system administrator decides which version is to be used in
> hes environment and which version is tested and compatible with
> corporate environment. Sometimes (most often) compatibility checks take
> somewhat more time than 5 minutes - so sysadmins might not like that all
> users automatically upgrade to any new version immediately.
>
> Additionally FF (AFAIK) fixed this strange behavior that it is
> downloading and trying to install an update even if the user has no
> rights to install it (non-admin). Therefore normal users are not asked
> to upgrade by FF itself.
Instead FF does the update without prior notification now ... and only
asks if you want to restart now or later =8<<

>
>
>> - include logical "or" check for the next Revision, e.g. 2.0.0.14 within
>> the recent 20013 package (see here:
>> http://wpkg.org/Firefox#Firefox_with_extensions_and_default_profile)
>
> Yes, this is an option - as outlined above. I still think it's not the
> best option to give this choice to the user. The Administrator should
> actually take care of the upgrade itself.
Ack.

>
> By the way - this "problem" is only caused by software packages which
> use their version number within the uninstall entry in the control
> panel. Actually I think applications should NOT use the version within
> the description string there. Most applications don't do (especially not
> showing patch-revision within this string).
Full Ack.

> The opposite you can do for your FF package. If you don't want to verify
> that a specific FF version is installed (which is inherently done when
> checking for the uninstall entry which contains the version number) then
> just check for the file _existence_ (not version) of the firefox.exe file.
Yes, you are right. In the mean time (after sending the mail of course :)
I had the idea to use "versiongreaterorequal" here, like in:

<check type="file" condition="versiongreaterorequal"
path="%programfiles%\mozilla firefox\firefox.exe"
value="2.0.0.12"/>

But this seems even unpossible to me, since in the properties of
firefox.exe we have a "file version" changing from "1.8.1.12: 2008020121"
to "1.8.20080.31114"  and a "product version" changing from 2.0.0.12 to
2.0.0.13.
Or can we distinguish between "file version" and "product version" within
the checks?

So, I'll next try checking only the existence of "firefox.exe". But I fear
that in the case there Firefox is already on the workstation and wpkg is
newly installed: this check succeeds with any (older) version of Firefox,
and nothing is done.


>> BTW:
>> * Is there a chance to do something like a "include" in xml (see the
>> template package in the above link for repeating parts of packages)?
>
> I don't think this is easily possible. WPKG web-gui could provide such a
> thing probably...
>
>
>> * Does your way of installing firefox using unattended.cmd prevent the
>> old-version-install?
>
> No. As I wrote above - if WPKG is configured to verify the version and
> executes the unattended.cmd script then I assume it is my real intention
> to enforce this version to be installed. If not, I just make sure that
> the checks are true no matter which version of FF the user installed.
>
> Of course you can also modify unattended.cmd to do some additional
> checks (for example checking that the version is 2.0.0.12 or higher, and
> NOT lower) and then skip installation. However this is truly application
> specific since this checks will look different for each application. So
> it's entirely correct to move them to a FF-specific unattended.cmd.
> The only drawback in this case would be that the checks of WPKG would
> always return false (uninstall entry not available) and then call
> unattended.cmd which probably skips installation completely as a newer
> version is already installed. I know this would be a very quick
> execution, but nevertheless it would require invoking of unattended.cmd
> each time unless the admin is going to upgrade the package.
Yes, this could be an option.

>
> Small side-note: There is a change request which request an extension to
> allow version checking of the uninstall entry as well. This will
> probably be part of WPKG 1.1+. Unfortunately I just checked and Firefox
> is using a version string like "2.0.0.13 (en-US)". I think it's an
> absolutely bad idea to put " (en-US)" to the version string - while
> keeping the version number within the uninstall string as well ("Mozilla
> Firefox (2.0.0.13)"). This would make a version equal check more
> difficult for this specific package. But for lots of other packages this
> might improve the situation. For FF it will anyway not help unless they
> finally remove this silly version tag from the uninstall entry.
Perhaps a "versiongreaterorequal" in uninstall string would be an option,
but with different software we will have different version numbering
schemes ...

Best regards,
Falko


-- 
Falko Trojahn                     fon +49-341-3581294
Dipl-Ingenieur Netzwerke/Support  fax +49-341-3581295
SMI Softmark Informationstechnologien GmbH