[wpkg-users] [Bug 149] Specify prerequisites for a package

bugzilla-daemon at bugzilla.wpkg.org bugzilla-daemon at bugzilla.wpkg.org
Mon Mar 30 23:18:57 CEST 2009


http://bugzilla.wpkg.org/show_bug.cgi?id=149





--- Comment #8 from Rainer Meier <r.meier at wpkg.org>  2009-03-30 23:18:50 ---
> > As I said a custom "execute" check can be configured already now. This check
> > could verify if the application should be applied on the system. If not, it
> > just returns exit code 0 to tell WPKG that the package is already installed.

> Just to be clear, here you are referring to an <install> element running a
> script command and that script checking the prerequisite status, right?

No. Actually here I was referring to a <check type="execute" .../> statement.
This allows the specified script to be executed and its exit value to be
evaluated.

e.g.
<check type="execute" condition="exitcodesmallerthan" value="1"
path="%SOFTWARE%\somescript.cmd" />

This script might return 0 now to indicate to WPKG that it is successfully
installed so WPKG will not run any install command and assume everything is
fine.


About my profile - of course I simplified it a little. However complexity and
amount of profiles is not a reason to introduce a bunch of unnecessary code
just because some users are unable to assign the right profiles to the right
machines.

Yes, in worst case you might end up having to assign an independent profile for
each node but creating your packages in a smart way it's easy to prevent.
For example almost all of my packages I apply on any node (no matter if it's
Windows 2000, XP, Vista or Windows 7, and yes, I use all of them). To Windows
2000 and Windows XP clients I usually assign the same profile and for Vista and
Windows 7 the same one works as well. 64-bit or 32-bit version does not matter
because 32-bit software runs perfectly on 64-bit OS and in the rare cases where
developers provide a special 64-bit edition I use my toolset (see attachment to
this report) to let the package decide automatically which package to install
(e.g. for TorotiseCVS or Java RT).

So finally I really end up more or less with the simple package structure I've
outlined. However it's clear that if you have lots of different "user profiles"
and you're really forced to provide a different set of software, then you have
to provide a profile for each of these "user profiles". So if somehow your
"backoffice" is unable to deal with the situation that TortoiseSVN is installed
on the system, you need to prepare a profile for them. Alternatively (and
that's what I outlined here) you might still apply the package and let a check
script detect if the package should be really installed or just be "skipped".
But still, I don't like that approach too much because you actually assign a
piece of software to a client which is then not installed in reality. So
somebody might think "oh yes, I can use this backoffice PC and do some
development too" while TortoiseSVN is actually missing on the system.

br,
Rainer


-- 
Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.



More information about the wpkg-users mailing list