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

[bugzilla-daemon at bugzilla.wpkg.org]

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


Rainer Meier <r.meier at wpkg.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |r.meier at wpkg.org




--- Comment #2 from Rainer Meier <r.meier at wpkg.org>  2009-03-30 19:21:06 ---
... I am quite sure that such a script fully supports all the use cases
required.

Actually the point is a different one. Some people would like to see every
possible feature packed into a single script which in turn gets unmaintainable
and extremely complicated (to program AND to use).

Recently I posted a bunch of installer scripts in the WPKG users mailing list
which provide a framework to automatically detect the Windows version
(64-bit/32-bit, language...) and then can run a different installer. In most
cases installers for different versions of Windows leave the same traces in the
system which makes it possible to specify a simple package check (e.g.
uninstall entry).

The problem I see in this request is that the number of checks and conditions
are quite infinte. Then WPKG should support all of them and soon somebody would
like to have another very specific check.

Instead what I am trying to provide is a framework and some samples which
allows every system administrator to adapt to its needs.


Taking the examples below there are already numerous requests:
- Windows version check
- check if software is already installed
- check Windows x64/x86

Thinking about it somebody could easily think about thousands of other requests
what should be supported to be checked:
- Registry value
- File existence
- WMI object query
- Query output of (proprietary?) tools
...


Here are some examples how you could solve the specific problems you mentioned
with existing WPKG versions:
> - Windows version check

Use an installer script which does the check for you.


> - check if software is already installed

WPKG is doing this already. If the checks specified in the package are true,
then WPKG just adds the package to the list in wpkg.xml without installing
anything.


> - check Windows x64/x86

Use an installer script which does the check for you.


Actually implementing all these possibilities into WPKG would mean to implement
a programming language which lets you implement you own algorithm to specify
which requirements need to be met in order to install the package and which
installer to run with which options.
But remember that such methods already exist. For example take a simple .cmd
script and implement whatever you need to check and evaluate. WPKG perfectly
supports this by specifying to run such a .cmd script instead of the installer
directly. WPKG does not care about what it runs, it just wants to have a proper
exit code of the "thing" it runs and it will verify the installation using the
given checks.

Also remember that you might even use an "execute" style check which allows to
execute a script too. The script could even return "0" (properly installed) in
case the software should not be applied on the system. So WPKG will skip
installation because it will think it's already applied on the system.


The basic rule about the package is clear: There is only ONE package per
software distribution. So on my system you will find only one single package
for TortoiseSVN (which installs 64-bit edition on 64-bit system and 32-bit
edition on 32-bit systems, but the package is the same) or OpenOffice.org
(which installs German version on German OS and English version on English OS).
Again, there is only one package called 'tortoisesvn' and 'openoffice' which is
applied on all systems.

I will attach my script-set to this bug report. They might help you to handle
such situations or give you some inspiration.


In general I think people should start to understand that WPKG will not solve
all possible situations out-of-the-box but it offers quite an open and
extensive approach which allows you to handle every situation. The advantage of
this approach is that we can focus on the basic functionality, it's well
tested, stable and maintainable by only a few (or single ;-)) developer.

If you have a special example where the offered functionality of WPKG does not
work for you at all please describe it in detail so somebody could actually
help you to solve the problem with existing functionality. I am quite sure it's
possible.

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.