[wpkg-users] Conditional installation of a package

[Rainer Meier]

Hi Johannes,

Johannes.Brix at evidian.com wrote:
> Hello Rainer,
> 
> let me explain my scenario:
> I have a bunch of different user groups: students, secretaries,
> consultants, managers, developers, support people.
> I created a hierachy in the profiles:
>    1st  level: I grouped packages
>    2nd level: I grouped the packages for my different usergroups.
> 
> This works fine, but now, one user got a new notebook with Vista and there
> are two applications, which do not work
> or which are no longer neccessary.
> 
> My idea was to check in the application package if the OS is Vista and then
> not to install the package.

Well, so you want to have a hack just for this one computer. To be 
honest I think this is quite a bad approach and makes the package 
structure difficult to maintain if there are lots of exceptions and 
pre-checks and the likely.

As I wrote you could use a cmd script in the install command definition 
which executes the actual installer only if the package should be 
applied to the host (by executing any number of script-internal checks). 
Just make sure that you pretend to WPKG that the package is actually 
installed. For example the script could write a text file (e.g. 
%SystemRoot%\softXinstalled.txt) and you add a new check to the package 
like:
- uninstall entry: softX installed
   OR
- file exists: %SystemRoot%\softXinstalled.txt

So the software will not be actually installed by WPKG but WPKG thinks 
it is. Thus not repeating the installation at each run.

However I think it's not the best solution. I would rather prefer to 
create a new profile for vista clients. Of course this could easily 
double the amount of profiles you have (one for XP, one for Vista). 
However in my eyes this is a good idea anyway as you do not have to 
double the maintenance effort. In most cases you just update the package 
definitions and the same packages are refered within XP profiles as 
within Vista profiles. So no update required later on.


Of course for some packages I also did similar things - I do some 
detection for "special" systems within the install script and I pass 
different parameters to the installer. However if a package is assigned 
to a node I generally want that this package is actually installed on 
that node - else I do not apply it to the node.



> An other case is that all applications we use can be installed on a PC with
> XP german on it.
> But from time to time, our support needs to setup PCs in english or french,
> and there are some applications
> which cannot be installed in them.
> Everythime the update is running, it tries again to install this package,
> but fails.

Also here - these machines need a profile which contains packages which 
are working for the machine. WPKG is designed to install software and 
make sure it is deployed. It is not designed to make decisions whether a 
software should probably be skipped or not depending on some rules.

The same as I wrote above applies here as well. You might write some 
packages which "skip themselves" when executing on an inappropriate node 
while keeping exit status 0 (successfully installed) - making WPKG think 
it is installed properly.

WPKG offers a lot of extension points and possibilities (like the ones 
described above) in order to do such "hacks". However I do not really 
recommend them as it makes it difficult to keep track of the actual 
software which is installed.
Imagine you're doing some "inventory" or copying the local wpkg.xml to a 
server. Then the package is actually listed there, indicating it is 
installed. However you are not sure if it is really installed or if the 
install script somehow skipped the installation (probably wrongly). So I 
really suggest to assign only packages to hosts which should be installed.

If you're not able to reduce the number of "machine classes" with 
different software base, this means that you have to maintain a profile 
for each of them (in worst case a list of packages for each node 
independently). This is not a problem of WPKG, it's a problem of 
planning. Operating an extremely heterogeneous environment also includes 
additional maintenance effort. It also includes additional testing 
effort as each package in theory would have to be tested on each machine 
independently to make sure it runs smoothly (if each environment looks 
slightly different). So I strongly advise administrators to operate as 
less "machine classes" (pools of machines with identical configuration) 
as possible.


> So, if I can state not to install a package if the language is not german,
> would be extremely helpfull.

WPKG does not have such a functionality. As I wrote above if you operate 
machines with different languages and a different package set I suggest 
creating different profiles:

- profile-langA
- profile-langB

If both profiles contain some packages in common you might use 
dependencies to minimize effort. For example I assume that the profiles 
differ only in a very limited number of applications (lots of 
applications are multi-language capable).
So the profile structure could look as follows:

- profile-global
   All applications applying to all profiles


- profile-langA
   depends on "profile-global" above.
   adds langA specific packages.

- profile-langB
   depends on "profile-global" above.
   adds langB specific packages.


Unfortunately you did not name which applications you're talking about. 
Up to now I managed to write one single installer for all OS languages 
for every software I used. Most of the time it is simply about different 
"c:\Programme" or "c:\Program Files" paths or the likely. By using 
%ProgramFiles% variable or a small script detecting the path it is 
usually possible to use the same application on various 
Windows-language-versions. An install script might also determine which 
language the OS runs on and then run a language-specific installer.


> And creating additional profiles for each exception would result in an
> unmanagable number of profiles,
> which we had before you added the "dependency" feature.
> 
> I hope, this makes my question more clear.

Yes, it does. I see your hints, however there is no easy way to solve 
it. By definition packages you add to a profile should be applied to the 
system (and not to be excluded due to some additional ruleset).

I gave some hints above how you could solve it. However if you really 
have that many "special" installations you are in any case creating a 
huge effort in terms of managing the "software package" for each machine 
independently. If the effort to support that many different environments 
is too high, then a company should think about reducing the number of 
independent platforms in order to reduce effort and cost.

Again, if each machine in a company would have its own list of software 
which should be managed by WPKG and each set is different, then this 
company would need a profile for each host for sure. Even that is not 
really a problem - an administrator could easily draw a tree to get an 
immediate overview which package is applied to which profile. 
Updating/changing a package is not a problem - it will apply to all 
nodes/profiles which include the package. Of course when a new package 
is introduced, then it needs to be decided to which profiles it should 
be added.

In most companies there are some IT-guidelines which clearly state which 
software is installed in which departments. So it is common to have a 
profile for each department. While in lots of companies most departments 
use the same software profile while there might be a couple of 
departments having custom requirements and custom profiles.

Applying special "rules" to packages where it is decided on each node if 
the software is applied or not creates some basic problems:
- System administrators says software X is installed on all nodes within 
finance department.

- Finance says software X does not exist on node a, b and c while it is 
installed on node d and e

This creates some hard to trace problems for system administrators. Here 
it might be easy to have a profile for node a, b and c and another 
profile for node d and e. So it's very easy to see if a software X 
should be installed on node a, b, c, d or e and WPKG will write such 
messages directly to the server if installation fails.


br,
Rainer