Falko Trojahn schrieb: > Hi, > >>> 2) Extra <check> rules; >>> I have "Battery" checks; to detect laptops, "Disk Size/Free" >>> checks; to prevent installs clogged up and failing from disk space >>> problems, "RAM" checks; to stop installs failing because of >>> pre-requisites. >> Hmm, shouldn't the installer check these requirements (diskspace, >> memory...) and fail with an appropriate exit code if it does not meet >> the minimum requirements? >> >> Checks are meant to check if an application is installed or not. If >> somebody would define a check like "memfree > 512MB" then this check >> would probably fail after next boot after the installation of some >> additional services. Thus triggering a check failure and making WPKG >> think the application is not installed. >> > > Regarding a check of disk space requirements, I think this would be a > really useful feature: from time to time I've got machines without > enough disk space to install e.g. office, acrobat8, sometimes even > updates (SP3 ...) etc. > > So it would be a really good idea to have something like a > "pre-flight-check" to check if the space for installation is available > before trying to install: > > If there is no check and not enough space, installers might hang issuing > an error dialog, installers make the machine really slow until they > recognize that there is not enough space to install and so on. > > Of course we might check for space in the pre action command of Wpkg > client (exit >= 0 if not enough space) - but this cannot be made > dependent from size of applications. > > What do you think about: > > <depends> > <check type="freespace" condition="greaterorequal" value="500" /> > </depends> I'm not very sure if integrating whole lots of tests inside wpkg.js is a good idea. Once we start integrating such checks (free space, free memory, wifi), I'm sure there will be other well-justified cases "worth integrating" (slow dial-up, VPN, CPU cores, CPU MHz, motherboard, hardware type etc., you name it). Also, making these tests via WPKG Client (via pre- task) is not ideal. Imagine this: a pre- task test which checks if there is enough free space; if not, it exits with a non-zero exit code. It prevents the execution of wpkg.js, and thus, a potential installation of a largish package; it also could prevent execution of a package which task is solely to remove free space... A no-no... How about introducing special types of packages? For example, if a package with a name "wpkg-check-*" exits with a non-zero exit code, wpkg.js would break its execution. Or better yet, it reacts in a specific way to different exit codes when a "wpkg-check-*" package is executed. This has an advantage that it can be executed anywhere, with different priorities etc. all infrastructure wpkg.js provides. Or, if not a dedicated package with a "wpkg-check-*" name, than maybe a special cmd prior to executing a proper installer: <install type="wpkg-check" cmd="%SOFTWARE%\wpkg-check-free-space.cmd"/> <install cmd="%SOFTWARE%\some-really-big-software.exe /silent"/> Just an idea - I may be totally wrong of course, and I'm sure there are better approaches, but it is certainly worth discussing. -- Tomasz Chmielewski http://wpkg.org |