David Petterson da...@ifm.liu.se writes:
I am testing WPKG combined with Dropbox to see if the combination
dropbox+download could be a solution for people out of office for
longer periods of time.
I keep the wpkg base and all xml files + tools in a network shared
Dropbox folder and all programs are downloaded using download
url='http://location/file.exe'/
So far so good, but now I found out that some packages on wpkg.org are
using variables for the version number, which would be very nice and
allow faster package updating when a new version arrive.
The problem I get is that the URL part of the download does not seem
to handle the %version% variable, however the target does.
ex: (url shorted to fit email better)
variable name=version value=10.0.0 /
download
url='https://wpkg/program/AdobeReader/AdbeRdr%version%_en_US.msi'
target=wpkg\AdbeRdr%version%_en_US.msi/
This will give the output (sorry about the line cuts):
Downloading
https://wpkg/program/AdobeReader/AdbeRdr%version%_en_US.msi' to
C:\Windows\Temp\wpkg\AdbeRdr10.0.0_en_US.msi'
Download failed: The parameter is incorrect.
As you can see the %version% was resolved only in the second part of
the command.
Found it line 6037 of wpkg.js, the target is expanded but not the url.
I wonder if it's a good idea to expand the url, what about encoding
characters in URL like:
#v+
http://fr.wikipedia.org/wiki/T%C3%A9l%C3%A9kin%C3%A9sie
#v-
I don't know the answer but my first guest is that the following will
cause troubles:
#v+
var url = 'http://fr.wikipedia.org/wiki/T%C3%A9l%C3%A9kin%C3%A9sie';
url = new ActiveXObject(WScript.Shell).ExpandEnvironmentStrings(url);
WScript.Echo(url);
#v-
Maybe it will be better to use server side redirection or something like
this, making the url stable?
If you are using network shared Dropbox to distribute wpkg folder, why
not using the same for the applications and avoid the need to use download?
Also, I would have a feature request.
All our computers have Adobe Reader installed by default, but some of
them have the full version.
I want the full version to block the installation of the reader to
avoid conflicts.
Maybe a check in the adobe package to test for the version of adobe
installed by the package or any newer or the full version?
Since we today can depend, chain include I think that block would be
a nice addition.
What is it supposed to do?
Maybe a package with a block package-id='other-package' will be
executed before the blocked one, and if the package is successfully
installed it must remove the 'other-package' from the package list?
In your case, this scenario seems to force you to have an adobe-full and an
adobe-reader packages.
If you need an just check package to catch an already installed adobe
full, why not adding the checks in the adobe-reader package with a
logical or check, like:
!-- Reader or full install --
check type='logical' condition='or'
!-- Reader check --
check type='uninstall' condition='exists' path='Adobe Reader 9.4.0 -
Français'/
!-- 32/64 bits checks --
check type='logical' condition='or'
check type='file' condition='versiongreaterorequal'
path='%ProgramFiles%\Adobe\Reader 9.0\Reader\Acrord32.exe'
value='9.4.0.195'/
check type='file' condition='versiongreaterorequal'
path='%ProgramFiles(x86)%\Adobe\Reader 9.0\Reader\Acrord32.exe'
value='9.4.0.195'/
/check
!-- Adobe full check --
check type='uninstall' condition='exists' path='Adobe whatever'/
!-- 32/64 bits checks --
check type='logical' condition='or'
check type='file' condition='versiongreaterorequal'
path='%ProgramFiles%\Adobe\whatever\whatever.exe'
value='whatever'/
check type='file' condition='versiongreaterorequal'
path='%ProgramFiles(x86)%\Adobe\whatever\whatever.exe'
value='whatever'/
/check
/check
Regards.
--
Daniel Dehennin
RAIP de l'Orne
pgpxJhOHibwLI.pgp
Description: PGP signature
-
wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/
___
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users
