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

[bugzilla-daemon at bugzilla.wpkg.org]

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





--- Comment #6 from Rainer Meier <r.meier at wpkg.org>  2009-03-30 22:16:42 ---
@#4

I think I've seen this request already once and either I don't get the point
how to simply implement it or you're simplifying a bit too much.

WPKG was always written in a way to be as simple as possible to use.
If I got it right you're proposing to have specific checks and if this check is
true then installation is enabled/disabled.

But let's have a look at this example:
<check type=install ...> so if this check is true then the package will be
installed.
<check type=prereq ...> So the package will be installed only if the specified
check is true? What's the difference to the previous one?

I really think it's not a good idea to mix two different concepts here. Checks
in WPKG are there to check if a package is actually installed or not (and only
for this purpose).

Introducing a <prereq> imposes a lot of changes and problems as well. For
example what will happen to packages which are assigned to a system which does
not meet the prerequirements? Of course the package should not be installed but
should WPKG try to install them each time (it could happen that next time the
system meets the requirements)?

So this is about the handling of check results. Then the type of checks require
additional development as well. Some might want to do registry checks, some
want to do file checks or whatever. Of course an "execute" check to execute a
script could be implemented as well, but then it's no better than the existing
checks.

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.

Since WPKG re-executes the checks on each run to re-verify if a package has
been removed it will also detect if the system later meets the requirements and
the check script then returns non-zero value so WPKG will install it.
So such a check script should have the following requirements:
- return 0 (installed) if the system does not meet requirements
- return 1 (not installed) if the system meets requirements but package is not
yet installed.
- return 0 (instlaled) if the system meets requirements and package is
installed.


For specific versions of Windows (e.g. very old Windows 98 machines) will most
probably anyway need a different profile assigned to them which does not even
try to install such a package.

For example for my deployments I use the following profile structure:
profile-default: Basic profile with common packages for all systems
profile-XP: Depends on "profile-default" and adds XP-only packages
profile-Vista: Depends on "profile-default" and adds Vista-only packages

The profiles are assigned to the hosts via hosts definition (for ease I use
machine-name prefixes like V* or XP* which are generated automatically during
setup.


A can only repeat what I wrote many times on the mailing list and in bug
reports. I think it's anyway a bad idea that packages which should not be
installed on a specific system are actually assigned to that system by the
host/profile definition. And nothing else you're describing here. You want to
assign packages to systems where the package should actually not be applied to
some of the systems you assign it to.
Above I described you a solution how this could already work without even
increasing complexity of WPKG at all, even without touching it because it
already supports it.
Now you might be able to show me how to do it with less code in WPKG? ;-)


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