[wpkg-users] Excluding particular OS and architecture types from patch application

[Rainer Meier]

Hi,

On 28.04.2010 17:06, Marco Gaiarin wrote:
> If this is a contest i definitely vote for a os='' and arch='' tag in
> nodes (<package, <install|upgrade|remove, ...).
> 
> I'm not a WSH programmer (i'm not a programmer at all ;), but seems to
> me that can be easily implemented without disrupt all the WPKG code (a
> simple condition before loading the node...).
> 
> I think that the source of check could be some environment variable
> (%WPKG_OS% and %WPKG_ARCH%?) that can be calculated on pre-script,
> without adding to WPKG code the 'os detection' code that can clearly be
> a mess.
> 
> If variables are not defined, simply mean 'all'.

I will definitely think about such a feature - or something similar. But I will
not include such a thing on short notice.
Meanwhile the scripts I provided do a great job at running different installers
on different platforms.
Even the logic behind quite simple. Instead of defining a profile which assigns
some packages only to specific OS or OS versions it just assigns the package to
the profile - no matter if the machines in this profile run OS x or OS y. The
package itself decides which parts need to be installed. Another nice example is
the Microsoft .NET package. Here I have only one single .NET package and it's
assigned to Windows XP, Vista and 7 nodes. On Windows XP it installs .NET
2.0/3.0/3.5/4.0 on Vista and 7 it just installs 4.0 automatically. This allows
me to maintain only one single package.

In addition I thin it's wrong to define in the package definition whether the
package should be applied to the node. I would rather prefer to define OS
dependency in profile specification. So one could specify that a specific
package is applied to the profile only if OS/Version matches.

In both cases there is a problem with dependencies. Let's take the example of
.NET again. If you split .NET 2.0, 3.0, 3.5 and 4.0 into 4 independent packages
and assign them to corresponding OS only, then it makes it harder for the admin
to define dependencies. For example CDBurner XP depends on .NET to be installed
in version 2.0/3.0 or 3.5 (but not 4.0). So if you define a dependency on .NET
2.0 package it will make WPKG to install it on the host - no matter if it is not
assigned by profile due to OS exclusion in profile specification.

So my approach is to have only one .NET package which just assures that all .NET
related dependencies are fulfilled and then I just make CDBurner XP depend on
this package. So the .NET package will do some more work on Windows XP than on
Vista or 7 but on all hosts it assures that all .NET versions are properly
installed. It's so simple.

Exposing some variables like WPKG_OS or WPKG_ARCH to the app/script run by WPKG
would probably simplify script-writing slightly. But honestly I don't see much
simplification for my scripts whether I have to write

if %WPKG_OS% EQU XP goto installXP

or

ver | findstr /i "5\.1\." > nul
IF %ERRORLEVEL% EQU 0 goto installXP



In case of WPKG_ARCH it's even more ridiculous since there is
"PROCESSOR_ARCHITECTURE" environment variable defined by the OS anyway.

So

if %PROCESSOR_ARCHITECTURE% EQU AMD64 goto install64bit

becomes

if %WPKG_ARCH% EQU AMD64 goto install64bit


Sure wpkg.js itself can be wrapped and called by any CMD script which evaluates
whatever convenient-variable you would like to expose to your scripts.


br,
Rainer