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 ------------------------------------------------------------------------- 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
