[wpkg-users] Announcement: WPKG 1.2.1-RC21
Rainer Meier
r.meier at wpkg.org
Mon Oct 10 02:16:30 CEST 2011
Hi,
It's not very common to announce release candidates but as there are a couple of
interesting pre-release changes in WPKG 1.2.1-RC21 I would like to announce it.
Hopefully you will find the enhancements useful.
I am looking for testers and feedback as well as bug reports as well.
As always the pre-release can be fetched from SVN directly:
<http://wpkg.svn.sourceforge.net/viewvc/wpkg/wpkg/stable/1.2/>
Usually it should be sufficient just to replace your local wpkg.js with the
latest 1.2.1-RC21 version.
If you're using XML validation make sure to get the updated XSD files as well.
Of course if you want to make use of the new command structure or conditional
XML nodes, then you will have to update your packages to use the new features.
===============================================================================
= CHANGES FOR 1.2 release
===============================================================================
Change notes
============
WPKG Version: 1.2.1-RC21
Author: : Rainer Meier <skybeam (at) users.sourceforge.net>
Date : 2011-10-10
Status : release pending
Changes/fixes visible to the user:
- Fixed possibility to catch "file not found" on command execution.
- Minor typo and formatting fixes.
- Fixed order of include for XML files from sub-directories.
- Further improvements on XML reading.
- Fixed one more bug when reading XML files from folders.
- Extended host attribute matching for checks.
- Ext. host attribute matching for dependencies, chain, includes and downloads.
- Fixed English LCID message in config.xml.
- Speed up termination of short-running tasks.
- Fixed literal sorting of XML files during read from directory.
- Updated logfile handling.
- Enhanced command-line parsing.
- Added qualifiers for command-line switches.
- Added lcidOS advanced host matching attribute.
- Fix for lcidOS reading.
- Printing WPKG version later during init process.
- Added extended host attribute matching for host/profile and profile/depends.
- Logfile handling improvement.
- Added expansion of environment variables in download URLs.
- Fixed download timeout.
- Fixed download during package removal.
- Fixed typo on reading expandURL attribute from download nodes.
- Added package command inclusion.
- New options to /query argument.
- Verious smaller fixes.
- Fixed XSD and moved installdate/uninstalldate to profile.
- Fixed quiet mode.
- Added file date comparison operation for checks.
- Fixed XSD package include.
- Improved handling of command include recursion detection.
- (Re-)fixed download tag.
- Updated package templates to include latest WPKG features.
- Limited file date equal comparison to 1-second resolution.
- Support for host checks in <check /> nodes.
- Condition support for extended host attribute check nodes.
- Added generic command type specification and inclusion.
- Enhanced variable resolution (recursive variables within same node).
FIX: Fixed another issue that specifying a command which could not be executed
(for example if the specified target did not exist) caused WPKG to report
an error which could not be catched by exit code "any".
Reverted behavior to pre-version-1.2. So WPKG in such cases returns exit
code "-1" which can be catched by an exit code "-1" or "any" statement.
Fixes bug 226. Thanks to Bruno Choquet for reporting.
FIX: Fixed minor typo and formatting. One bug regarding code typo is likely
never going to be executed in production. So no real impact on live
systems expected.
FIX: Potential fix for changed XML parsing where XML database file is included
to the XML tree before files in sub-directory. For example host.xml was
read before hosts/*.xml files. Therefore if hosts.xml did include a
"catch-all" entry (e.g. name=".*") it was always taken into account first
no matter if there is a more-specifc match in any hosts/*.xml files.
Now WPKG first parses hosts/*.xml files (in literal order) and then reads
hosts.xml. Thus if there is a concrete match within any hosts/*.xml file
this match takes precedence.
Note that this change does not have any effect if applyMultiple is not
enabled. If applyMultiple is enabled then anyway all host matches are
evaluated.
Thanks for Marco Gaiarin for initiating the discussion.
FIX: Fixed reading of XML files. Specifically reading the root node including
attributes. The change also includes simplified XML handling. The XML
root node name is now read from the first XML file in the list (either
the file passed as argument or from the first file read from the XML
directory). Therefore the XML root node name parameter is not needed any
more. The change also eliminates the requirement for XSL transformation
in case only a single file is loaded. This might speed up single-file
reading.
FIX: Fixed reading multiple XML files from directory. The last commit included
too many optimizations and did not take into account that MSXML creates a
new XML document when loadXML() is used on a XML DOM object instead of
just modifying the existing one. So the root element has to be re-read.
NEW: Added extended host matching for <check /> nodes. This enables to specify
checks like:
<check type="uninstall"
condition="exists"
path="Mozilla Firefox 5.0.1 (x86 en-US)"
architecture="x86"
/>
<check type="uninstall"
condition="exists"
path="Mozilla Firefox 5.0.1 (x64 en-US)"
architecture="x64"
/>
So you can specify individual checks based on specific host matches like
the host architecture, OS or other attributes.
Thanks to "cleitet" for suggestion. Fixes bug 205.
NEW: Added extended host attribute matching support for the following package
notes:
<depends />
<include />
<chain />
<download />
As a result the following nodes cannow deal with extended host matching:
In hosts.xml:
<host name="..." proifile-id="..." os="..." ... />
<variable name="..." value="..." os="..." ... />
In profiles.xml:
<variable name="..." value="..." os="..." ... />
<package package-id="..." os="..." ... />
In packages.xml:
<variable name="..." value="..." os="..." ... />
<depends package-id="..." os="..." />
<include package-id="..." os="..." />
<chain package-id="..." os="..." />
<download url="..." target="..." os="..." />
<install cmd="..." os="..." />
<upgrade cmd="..." os="..." />
<downgrade cmd="..." os="..." />
<remove cmd="..." os="..." />
FIX: Fixed start notification text in English LCID specification in config.xml:
From: ...Plase safe all...
To: ... Please save all...
Thanks for Jeff Applegate for pointing this out.
FIX: Fixed long execution run times if many short-running external commands are
invoked. For example if many execute-style checks were invoked and each
check finished its task in less than 1s time, then WPKG would wait at
least 1 second for it to finish. Unfortunately WSH is not very advanced in
handling child processes but the algorithm has been changed in a way that
for the first 100ms of run time the child status is checked every 10ms.
For the next 1000ms the status is checked every 100ms. If the task is not
finished by then the task will be checked for termination once per second.
This allows short-running tasks to terminate quickly while preventing high
WPKG load for monitoring on long-lasting tasks.
Fixes bug 233. Thanks to Malte Starostik für suggestion.
FIX: XML files read from directories (e.g. hosts/*.xml, profiles/*.xml or
packages/*.xml) have not been explcitly sorted. So the order of reading
was depending on the OS and not strictly defined.
Now all files are added to an array which is sorted in literal (ASCII)
order. Keep in mind if you number your files that sort oder is literally
and not numerically. So if you name your files "1.xml, 2,xml, 3.xml,
10.xml, 11.xml, 20.xml" then the sort order will be:
- 1.xml
- 10.xml
- 11.xml
- 2.xml
- 20.xml
- 3.xml
To prevent this try keeping the same amount of digits:
- 01.xml
- 02.xml
- 03.xml
- 10.xml
- 11.xml
- 20.xml
Thanks to Donny Brooks who seems to have noticed first that the ordering
somehow goes wrong for him.
MOD: Updated log file handling. Now there is no intermediate local log file
created any more. Instead a log is kept in memory as long as the log file
is not initialized. If anything goes wrong WPKG still tries to flush the
logs at least to a log file in %TEMP%.
This potentially increases efficiency and execution speed slightly.
MOD: Enhanced parsing of command-line parameters.
Enhances efficiency and potentially increases startup speed.
MOD: Added possibility to add true/false qualifiers to explicitly enable or
disable a value on command line. As requested in bug 234.
For example the following parameters are now supported:
/quiet Enables quiet mode.
/quiet:true Same as above. Enables quiet mode.
/quiet:false Explicitly disables quiet mode.
/nonotify Disable user notification.
/nonotify:true Same as above. Disables user notifications.
/nonotify:false Explicitly re-enable user notifications.
...
Check 'cscript wpkg.js /help' for details.
Thanks to Ben Hay for reporting.
NEW: Added new advanced host matching attribute "lcidOS" which matches against
the executing host InstallLanguage attribute found at
HKLM\SYSTEM\CurrentControlSet\Control\Nls\Language.
The use is identical to all other advanced host matching attributes.
e.g.
<install cmd="..." os="..." lcidOS="409" />
<upgrade cmd="..." os="..." lcidOS="409" />
Implemented as requested by Stefan Pendl and "grigribou".
FIX: Fixed reading of system locale. The registry path was broken due to typo.
Thanks to Grég B. for reporting.
FIX: Printing WPKG version later during initialization to prevent debug
messages appearing in logs even if lower log levels are configured.
NEW: Added full extended host attribute matching for <profile/> nodes in
host definitions and <depends/> nodes in profile definitions.
Some examples...
Assigning profiles depending on extended host attribute matching:
<host name="...">
<profile id="default" os="windows xp" architecture="x86" />
<profile id="default-x64" os="windows xp" architecture="x64" />
</host>
Of course the following is still possible too:
<host name="..." profile-id="default-x64" architecture="x64" />
Adding dependencies based on host attributes:
<profile id="default">
<depends profile-id="default-x64" architecture="x64" />
</profile>
As a result the following nodes cannow deal with extended host matching:
In hosts.xml:
<host name="..." proifile-id="..." os="..." ... />
<profile id="..." os="..." ... />
<variable name="..." value="..." os="..." ... />
In profiles.xml:
<variable name="..." value="..." os="..." ... />
<package package-id="..." os="..." ... />
<depends profile-id="..." os="..." ... />
In packages.xml:
<variable name="..." value="..." os="..." ... />
<depends package-id="..." os="..." />
<include package-id="..." os="..." />
<chain package-id="..." os="..." />
<download url="..." target="..." os="..." />
<install cmd="..." os="..." />
<upgrade cmd="..." os="..." />
<downgrade cmd="..." os="..." />
<remove cmd="..." os="..." />
Thanks to Malte Starostik for providing input.
FIX: Further improvement on log file handling. Now the log file is not even
opened if there is nothing to log. So if WPKG does not have anything to do
and log level is set to 0x07 or lower, then WPKG will not even create an
empty log file. Previous releases did create an empty log file in this
case.
NEW: Expansion of environment variables in download URLs added.
This allows specification of URLs with variables like the following:
<download
url="http://host/%VERSION%/release-%version%.exe"
target="release.exe"
/>
Note: As URLs are used to contain some percentage characters (like "%20"
for spaces) these might be expanded too if the URL matches an environment
variable which is defined. For example downloading from an URL like
url="http://host/softwareX%20release%20.exe" would try to expand the
environment "20release" as well. It's very unlikely that this collides
with an environment variable you have actually defined but keep it in mind
when defining download URLs.
If you really need to disable expansion because the URL collides with
existing environment variables then use the expandURL="false" attribute:
<download
expandURL="false"
url="http://host/softwareX%20release%20.exe"
target="release.exe"
/>
FIX: Fixed a bug that timeout value did not have any effect on download nodes.
FIX: Download nodes were not evaluated during package removal.
During package install/upgrade/downgrade WPKG reads <download /> nodes
from either the package or as a sub-node of the command-node. During
package removal no download nodes have been taken into account even though
it was documented to be supported.
This has been fixed now.
Fixes bug 193.
FIX: Fixed typo in reading expandURL attribute from download nodes.
Fixes Bug 202. Thanks to mback2k for reporting.
NEW: Allow command inclusion. Incluiding a complete set of commands is done
as follows:
<install include="remove" />
This would include all <remove /> commands into the install command list.
WPKG also supports mixing of inclusion and real commands. For example:
<upgrade include="remove" />
<upgrade cmd="%SOFTWARE%\system-preparation" />
<upgrade include="install" />
This example would first execute all defined <remove /> commands, then
execute the "system-preparation" binary and after this execute all defined
<install /> commands.
WPKG includes a detection for recursive inclusions. For example:
<install include="upgrade" />
<upgrade include="install" />
<upgrade cmd="%SOFTWARE%\some-binary" />
THis will make WPKG complain about recursion. WPKG will just ignore the
recursive inclusion of <install /> but sill execute "some-binary" during
the install process.
Check the logs for recursion errors (severity: error).
This change is supposed to fix bug 184 (resp. enhancement request).
Thanks to Stefan Pendl for suggesting.
Fixes/implements enhancement request 188 as well. Thanks to Peter Hoeg.
NEW: Implemented new options for the /query argument. It now supports the
following options:
a Query all packages.
x List packages which are not installed but in package database.
i List all packages which are currently installed.
I List packages which are about to be installed during
synchronization.
u List packages which are about to be upgraded during
synchronization.
d List packages which are about to be downgraded during
synchronization.
r List packages which are about to be removed during synchronization.
m List all modifications which would apply during synchronization
(equal to Iudr)
n List packages which belong to the profile but are not modified
during synchronization.
The options can be combined. For example /query:du would print just
packages which are about to be upgraded or downgraded during next
synchronization.
The "m" option is a shortcut for /query:Iudr. So if you want to get a
full list of all changes which will happen during next synchronization
just use /query:m.
Another example:
If you want to see the list of packages as it will be after the next
synchronization just use /query:Iudn. This will list packages which are
new (I), upgraded (u), downgraded (d) and the ones which are already
applied and are not modified (n).
FIX: Fixed a couple of bugs in install function which only affected very rare
cases.
FIX: Fixed bug in XSD. Packages do not have installdate/uninstalldate
attributes. Instead this attribute is supported within a package-
assignment in the profile only. Moved attribute from package to profile.
FIX: Fixed bug that quiet mode was always on by default (should default to off)
and therefore debug messages were sent to event log.
Thanks to Heiko Helmle for reporting.
NEW: Added file date comparison operations to checks. Basically you can compare
- file creation date
- file modification date
- file access time
You can compare the date to a date string passed in the value attribute or
compare to an existing file.
Basic syntax example:
<check type='file'
condition='datecreatenewerthan'
path='%SystemDrive%\test.txt'
value='@%SystemDrive%\test-comparison.txt' />
Valid conditions are:
- datemodifyequalto (Modify date equal to)
- datemodifynewerthan (Modify date newer than)
- datemodifyolderthan (Modify date older than)
- datecreateequalto (Create date equal to)
- datecreatenewerthan (Create date newer than)
- datecreateolderthan (Create date older than)
- dateaccessequalto (Access date equal to)
- dateaccessnewerthan (Access date newer than)
- dateaccessolderthan (Access date older than)
The 'value' attribute has to contain a string in the following format:
Relative timestamp (in minutes):
-100 Means the file timestamp is compared to the timestamp 100
minutes ago.
+50 Means the file timestamp is compared to the timestamp 50
minutes in the future.
Absolute timestamp in ISO 8601 format:
"2007-11-23 22:00" (22:00 local time)
"2007-11-23T22:00" (Both, "T" and space delimiter are allowed)
"2007-11-23 22:00:00" (specifies seconds which default to 0 above)
"2007-11-23 22:00:00.000" (specifies milliseconds which default to 0)
It is allowed to specify the timezone as well:
"2007-11-23 22:00+01:00" (22:00 CET)
"2007-11-23 21:00Z" (21:00 UTC/GMT = 22:00 CET)
"2007-11-23 22:00+00:00" (21:00 UTC/GMT = 22:00 CET)
File-Comparison:
Prefix your value with the '@' character in order to point to a file to
which the timestamp of the file referred in path is compared.
Examples:
@%SystemRoot%\explorer.exe
@c:\myfile.txt
Special terms:
last-week Check afainst timestamp of exactly one week ago (7 days).
last-month Check afainst timestamp of exactly one month ago (30
days).
last-year Check afainst timestamp of exactly one year ago (365
days).
yesterday Check afainst timestamp of yesterday (24 hours ago).
Some more examples:
Check if file has been modified after 15th of September 2011 15:00:
<check type='file'
condition='datemodifywerthan'
path='%SystemDrive%\test.txt'
value='2011-09-15T15:00' />
Check if file has been accessed within the last week:
<check type='file'
condition='dateaccessnewerthan'
path='%SystemDrive%\test.txt'
value='last-week' />
Check if file is older than one day (24 hours):
<check type='file'
condition='datecreateolderthan'
path='%SystemDrive%\test.txt'
value='yesterday' />
Check if file is older than 12 hours (720 minutes)
<check type='file'
condition='datecreateolderthan'
path='%SystemDrive%\test.txt'
value='-720' />
Implements change requested in Bug 147.
Thanks to Jason Oster.
FIX: Fixed XSD of packages. Command-nodes are included using the 'include'
attribute.
Thanks to Stefan Pendl for reporting.
FIX: Improved handling of recursive command inclusion. Inclusions where the
loop did not include the root element were not detected properly. For
example:
upgrade -> remove -> downgrade -> remove
This did cause an unhandled infinite loop.
The new implementation will detect it and ignore the inclusion of remove
from downgrade (printing an error to the log).
FIX: Fixed download tag. Thanks for Heiko Helmle for reporting and providing
fix.
NEW: Updated package templates to include latest WPKG features.
Thanks to Stefan Pendl. Fixes bug 238.
NEW: Updated package templates to include latest WPKG features.
Fixes bug 238. Thanks to Stefan Pendl.
NEW: When doing file date equal comparison to a date entered in ISO8601 format
then milliseconds are ignored. So the comparison resolution is limited to
1 second intervals.
WPKG still applies full millisecond resolution when comparing to reference
files or when using the olderthan/newerthan operators.
Fixes bug 237. Thanks to Stefan Pendl.
NEW: Added support for "host" checks in <check /> nodes. All additional host
check attributes are supported. Some examples:
<check type="host" condition="hostname" value="^hostname$" />
<check type="host" condition="os" value="windows 7" />
<check type="host" condition="architecture" value="x64" />
NEW: Enhanced host attributes check modification applied. Now all XML nodes
which support enhanced host attribute checks also allow more complex
"condition" checks.
Conditions specify whether the given node is applied or simply ignored
by WPKG. The checks supported are identical to the checks supported for
package installation.
Here are some examples...
Conditional installation
------------------------
<profile id="default">
<package id="pidgin" >
<condition>
<check type="uninstall" condition="exists" path="Pidgin" />
</condition>
</package />
</profile>
Apply a package only if it is already installed. For example this could
be used if users are allowed to install software. In case Pidgin was
already installed when WPKG is run, then the package is applied.
Caution: Your checks have to match the old and the new version on future
updates. If you forget to update the check for future versions then you
might end up with a profile which "lost" this package after upgrade and
therefore results in uninstall on subsequent runs.
For example an application with an uninstall entry of "App 1.0" should
be checked for "App.*" (regular expression) instead of checking the full
"App 1.0" string. Since later versions are likely to be named "App 1.1"
or similar the condition will not match it and therefore the package is
removed from the profile.
Advanced host check (new style)
-------------------------------
Conditions combined with the new "host" type checks introduced in this
update allows you to specify host checks in more advanced way. One
example:
<package id="pidgin" revision="1">
<install cmd='setup-32.exe ...'>
<condition>
<check type="host" condition="architecture" value="x86" />
</condition>
</install>
<install cmd='setup-64.exe ...'>
<condition>
<check type="host" condition="architecture" value="x64" />
</condition>
</install>
</package>
This definition is identical to:
<package id="pidgin" revision="1">
<install cmd='setup-32.exe ...' architecture="x86" />
<install cmd='setup-64.exe ...' architecture="x64" />
</package>
Sure the later one (old style) is much shorter but offers less flexibility
in terms of logical condition chaining. Moreover future attributes might
clash with future attributes.
The following construct would be possible too:
<package id="pidgin" revision="1">
<install cmd='setup-64.exe ...'>
<condition>
<check type="logical" condition="or">
<check type="host" condition="architecture" value="x64" />
<check type="host" condition="os" value="windows 7" />
<check type="logical" condition="and">
<check type="uninstall" condition="exists" path="some-prog" />
<check type="registry" condition="exists" path="HKLM\..." />
</check>
</check>
</condition>
</install>
</package>
This would execute "setup-64.exe" only if either the architecture is x64,
the OS string matches "windows 7" or if "some-prog" is installed along
with a registry key.
NOTE: Currently both advanced host checks are supported, the old
attribute-style and the new check-style using condition XML nodes.
In future versions of WPKG the attributes might be dropped.
NEW: Commands can now be defined in a more well-grouped format:
<package id='pidgin' name='Pidgin IM' revision='2.10.0'>
<check type='uninstall' condition='exists' path='Pidgin' />
<commands>
<command type="install" cmd='"%SOFTWARE%\..."' />
<command type="remove" cmd='"%SOFTWARE%\..."' />
<command type="upgrade" cmd='"%SOFTWARE%\..."' />
<command type="downgrade" cmd='"%SOFTWARE%\..."' />
</commands>
</package>
It's also allowed to mix old and new style where old-style commands are
installed first:
<package id='pidgin' name='Pidgin IM' revision='2.10.0'>
<check type='uninstall' condition='exists' path='Pidgin' />
<install type="install" cmd='"%SOFTWARE%\install1.cmd"' />
<commands>
<command type="install" cmd='"%SOFTWARE%\install2.cmd"' />
<command type="remove" cmd='"%SOFTWARE%\..."' />
<command type="upgrade" cmd='"%SOFTWARE%\..."' />
<command type="downgrade" cmd='"%SOFTWARE%\..."' />
</commands>
</package>
Here WPKG would first install "install1.cmd" and then "install2.cmd".
This is still the case if the commands are re-ordered:
<package id='pidgin' name='Pidgin IM' revision='2.10.0'>
<check type='uninstall' condition='exists' path='Pidgin' />
<commands>
<command type="install" cmd='"%SOFTWARE%\install2.cmd"' />
<command type="remove" cmd='"%SOFTWARE%\..."' />
<command type="upgrade" cmd='"%SOFTWARE%\..."' />
<command type="downgrade" cmd='"%SOFTWARE%\..."' />
</commands>
<install type="install" cmd='"%SOFTWARE%\install1.cmd"' />
</package>
Here still "install1.cmd" is launched first and then "install2.cmd".
This new style of commands also allows you to specify any artificial name
for type and refer to it in includes.
For example:
<package id='pidgin' name='Pidgin IM' revision='2.10.0'>
<commands>
<command type="install" include='prepare' />
<command type="install" cmd='"%SOFTWARE%\install.cmd"' />
<command type="install" include='cleanup' />
<command type="remove" include='prepare' />
<command type="remove" cmd='"%SOFTWARE%\remove.cmd"' />
<command type="remove" include='cleanup' />
<command type="upgrade" cmd='"%SOFTWARE%\upgrade.cmd"' />
<command type="downgrade" cmd='"%SOFTWARE%\downgrade.cmd"' />
<command type="prepare" cmd='"%SOFTWARE%\prepare1.cmd"' />
<command type="prepare" cmd='"%SOFTWARE%\prepare2.cmd"' />
<command type="cleanup" cmd='"%SOFTWARE%\cleanup.cmd"' />
</commands>
<install type="install" cmd='"%SOFTWARE%\install1.cmd"' />
</package>
In this example WPKG would launch the following commands during
installation;
- prepare1.cmd
- prepare2.cmd
- install.cmd
- cleanup.cmd
During remove the following commands would be run:
- prepare1.cmd
- prepare2.cmd
- remove.cmd
- cleanup.cmd
NOTE: WPKG will not run any of the "prepare" or "cleanup" commands
automatically if not included by command types known to WPKG (install,
remove, upgrade or downgrade at time of writing).
This is supposed to implement as well a request by Peter Hoeg
submitted in Bug 184.
FIX: Enhanced recursive variable evaluation. Variables can now be used within
other variable definitions as long as they are specified in correct order.
For example specifying the following shall work now:
<variable name="ext_id" value="{e2fda1a4-762b-4020-b5ad-a41df1933103}" />
<variable name="ext_dirname" value="lightning" />
<variable name="instdir" value="%PROGRAMFILES%\Mozilla \
Thunderbird\extensions\%ext_id%" />
...
Note that the last variable included a variable which is defined within
the package itself. Previously it was only allowed to include variables
which were defined at a different level (host, profile...).
Fixes bug 236. Thanks to Kalyniak Oleksandr.
br,
Rainer
More information about the wpkg-users
mailing list