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. |