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

[Lukasz Zalewski]

On 28/04/2010 16:38, Rainer Meier wrote:
> 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.
Rainer,
Would you consider reviewing/accepting a patch if i was going to submit one?

> 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.
 From the previous posts i observed that there are many diffrent ways 
people use wpkg to manage software updates. .NET package that you 
mentioned applies to all of OS releases, its just different versions for 
different OS'es. The case i had in mind was when package can exist only 
on a particular OS release and not the others, such as OS specific 
Service Pack.
>
> 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.
Do you mean something along the lines
<package package-id="7zip" OSGreaterorequal="6.1" />
That is interesting, however i think conceptually the OS and arch 
dependency belongs to the package itself rather than its profile 
assignment.
Below you mentioned package dependencies - in this statement the 
condition will not be processed if some other package depends on 7zip as 
the conditioning is done in package assignemnt
>
> 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 at lists.wpkg.org
> http://lists.wpkg.org/mailman/listinfo/wpkg-users

Luk