Difference between revisions of "Packages.xml:French"

Revision as of 06:49, 11 June 2007

packages.xml est un fichier qui définit comment installer et désinstaller des paquets logiciels. En d'autres mots, c'est une liste de tous les paquets et scripts pouvant être déployés ou exécuter sur les stations de travail.

Ce fichier doit être placé dans le même répertoire que wpkg.js.

WPKG ne fonctionnera pas sans ce fichier.

Structure de packages.xml

La structure de packages.xml ressemble à :

<packages>
<package
id="wpkg1"
name="Windows Packager exemple 1"
revision="1"
reboot="false"
priority="0">
<check type="registry" condition="exists" path="HKLM\Software\wpkg\full\key\not\part\of\it" />
<check type="file" condition="exists" path="%PROGRAMFILES%\wpkg\wpkg.bat" />
<check type="uninstall" condition="exists" path="WPKG" />

<install cmd='msiexec /i (chemin du paquet msi)'>
<exit code="0" />
</install>

<remove  cmd='%PROGRAMFILES%\uninstall\uninst.exe -quiet' />

<upgrade cmd='msiexec /i (chemin du paquet msi)' />

</package>

</packages>

Chaque paquet a les attributs suivants :

• id - Un identificateur unique représentant le paquet. Doit être court et pertinent.

• name - La version longue. Le nom complet du produit.

• revision - Un entier défini par l'utilisateur représentant la "version" du paquet. Doit être incrémenté à chaque nouvelle release.

• reboot - Si égal à "true", le système redémarre à la fin de l'installation, de la desinstallation, de la mise à jour du paquet.

• priority - Specifies a numeric value that determines in what order a package will be installed. The higher the number, the higher the priority, and so the earlier the package will be installed compared with lower priority packages. For example:
  • 2 - installs these packages 1st
  • 1 - installs these packages 2nd
  • 0 - installs these packages 3rd

Note that a package installer with priority '5' would install before all these.

Check conditions / check type

Of course it would be unwise to launch the installer if the software is already installed. That's why there are "check conditions".

Check conditions are broken down into 3 categories:

• Registry - Checks the registry for conditions
• File - Verifies various information about files within the filesystem
• Uninstall - Checks the software installation registry key (as displayed in Windows' Add/Remove Programs section) for the existence of an existing package

Registry

Registry checks allow you to check for the existence of or a specific value in a registry key. There are two possible conditions available for registry checks: exists and equals.

Examples:

This checks for the existence of Adobe Reader within the registry:

<check type="registry" condition="exists" path="HKLM\Software\Adobe\Adobe Reader\7.0" />

This checks to see if Firefox, US English, version 1.5.0.6, is installed:

<check type="registry" condition="equals" path="HKLM\Software\Mozilla\Mozilla Firefox\CurrentVersion" value="1.5.0.6 (en-US)" />

File

File checks allow you to check for the existence of a file, check for a particular file's size, or examine version information about a file. There are several possible conditions available for file checks:

Examples:

This checks for the existence of Adobe Reader within the filesystem:

<check type="file" condition="exists" path="%PROGRAMFILES%\Adobe\Acrobat 7.0\Reader\AcroRd32.exe" />

This checks to see if Firefox US English version 1.5.0.6 is installed based on the file size of the executable:

<check type="file" condition="sizeequals" path="%PROGRAMFILES%\Mozilla Firefox\firefox.exe" value="7183469" />

This checks whether the version of Firefox .exe that's currently installed is less than 1.5.0.6:

<check type="file" condition="versionsmallerthan" path="%PROGRAMFILES%\Mozilla Firefox\firefox.exe" value="1.5.0.6" />

Uninstall

Uninstall checks allow you to check the Microsoft software installation registry keys (as displayed in Windows' Add/Remove Programs section) for the existence of a particular package. Microsoft maintains the list of applications installed and available for uninstallation in the HKLM\Software\Microsoft\Windows\Current Version\Uninstall registry key. The value in the DisplayName key of a particular package is what's matched by this check. The only condition available for this option is exists.

Examples:

This checks for the existence of Adobe Reader through the installation list:

<check type="uninstall" condition="exists" path="Adobe Reader 7.0" />

This checks to see if Firefox version 1.5.0.6 is installed in the installation list:

<check type="uninstall" condition="exists" path="Mozilla Firefox (1.5.0.6)" />

Logical Conditions

There can be zero or more conditions verified during the existence checks. If no conditions are supplied, WPKG attempts to install the package regardless of whether it's currently installed or not. To facilitate using more than one condition, there is a 4th type of condition that can be added, called the logical condition. Logical conditions allow you to create multiple conditions while checking for the presence of an existing package. Logical conditions are top level conditions, with the real check conditions as subnodes in the XML.

The following logical conditions are available: not, and, or, atleast, and atmost.

Examples:

Let's say, for the sake of argument, that you have an Adobe Reader 7.0.8 package that you want installed, but you only want it installed on workstations that are running Windows XP Service Pack 2 or higher, due to some strange incompatibility. Let's also say that some workstations can't be upgraded to Windows XP Service Pack 2 until those workstations are upgraded from 256MB of memory to 512MB of memory. For a scenario like this, you could (and probably should!) use multiple profiles and have those SP1 workstations in one profile, while the SP2 workstations are in another. However, just for example purposes, let's say all workstations are in a single profile. You can provide a logical condition in order for only those workstations running SP2 to be upgraded to Adobe Reader 7.0.8:

<check type="logical" condition="or">
   <check type="registry" condition="exists" path="HKEY_LOCAL_MACHINE\SOFTWARE\Adobe\Acrobat Reader\7.0\Installer\Updates\708" />
   <check type="registry" condition="equals" path="HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\CSDVersion" value="Service Pack 1" />
</check>

The 2nd condition here might seem counter intuitive, but remember that you're looking for the absence of things rather than the existence of things when you're writing check conditions. What the above condition says is "Is Adobe Reader 7.0.8 installed or is Service Pack 1 installed? If either of these conditions equates to true, the installation will be skipped. In this particular case, Adobe Reader 7.0.8 isn't installed, but the value of CSDVersion is Service Pack 1 (for the SP1 boxes) so the software will not be installed.

Once all conditions have been tested, if the final result of the conditions is equal to false, WPKG will try to execute the "install cmd".

After it's executed, WPKG will check the exit code (should be 0 in this example) *and* verify all the checks.

If *any* of the checks are not met, software is considered *not* installed - so enter these values carefully!

Remember that you don't have to specify all three check conditions, usually one is enough: if the software you are about to install will show up in Windows' Add/Remove Programs (and not all do), it is sufficient to specify just the "uninstall" check.

Actions

Wpkg understands three actions: install, upgrade and remove. Multiple commands for each of these actions can be listed in the config file and wpkg will execute them in the order they are listed.

The install commands are executed by wpkg when a new package comes into scope for a profile. The upgrade commands are executed when a new revision of a package comes into scope. The remove commands are executed when a package is removed from a profile.

In many of the examples in the Category:Silent_Installers section, cmd.exe is executed to perform environment variable expansion and to use 'start /wait' to wait on the command being executed. This method of executing commands results in cmd windows appearing on screen. However, this method does not appear to be necessary. The current version of wpkg (0.9.10) executes commands using the WScript.Shell.Exec() function, which should expand environment variables. This isn't explicitly stated in the Microsoft SDK documentation, but seems to be the case. Wpkg then waits until the command is completed before continuing.

The correct method of executing a command interpreter is to use the %comspec% environment variable, not specifying cmd.exe explicitly. This is needed to run commands that are built into the interpreter and are not separate executables.

When the ouput of a command (think of: copy,cacls) is too much, the command will fail. You have to redirect the output to NUL or a file (example: "%command% >nul").

Typical examples:

<install cmd="msiexec /qn /i %SOFTWARE%/package.msi" />
<install cmd="msiexec /qn /i %SOFTWARE%/package.msi" timeout="1800" />
<install cmd="%comspec% /c copy %SOFTWARE%/file.dll %WINDIR%" />
<remove cmd="msiexec /qn /x %SOFTWARE%/package.msi" />

The timeout option tells wpkg how long to wait for the command to complete. It is in seconds and the default is 3600 seconds.

You can set reboot to "true" with the following:

<install cmd="msiexec /qn /i %SOFTWARE%/package.msi" >
    <exit code="3010" reboot="true" />
    <exit code="0" />
</install>

Quick examples

Other example - WPKG checks if the package is installed only in Windows' Add/Remove Programs before deciding to install it (to make sure it is not installed already):

<package
id="wpkg3"
name="Windows Packager sample 3"
revision="1"
reboot="false"
priority="1">

<!--
This is a comment.
Checks in Windows' Add/Remove Programs only.
-->
<check type="uninstall" condition="exists" path="WPKG" />

<install cmd='%PACKAGES%\package.exe /quiet /install' />

<remove  cmd='%PACKAGES%\package.exe /quiet /uninstall' />

<upgrade cmd='%PACKAGES%\package.exe /quiet /install' />

</package>

In the example below, there are no check conditions. This means that WPKG will execute it each time - so this is rather useful for executing scripts that need to be run each time the machine is booted, than installing software:

<package
id="backupfiles"
name="Makes backup of some file"
revision="1"
reboot="false"
priority="0">

<!--
This is a comment.
'''No check conditions; script will be executed *each time* wpkg.js is called - each time PC is booted.'''
-->

<install cmd='\\server\path\script.bat' />
</package>

Similar example, without any conditions, either. Note the execute="once" entry - this means that that script will be executed only once. It is useful for the tasks you want to do one time only, like disk defragmenting, some testing, changing printers etc.

<package
id="backupfiles"
name="Makes backup of some file"
revision="1"
reboot="false"
execute="once"
priority="0">

<install cmd='\\server\path\script.bat' />
</package>

Similarly, you may want to execute a program or script each time - use "always" instead of "once". For more info on this functionality, check here.

Package dependencies

Packages can also depend on other packages, see package dependencies for more info.

Définir des fichiers XML individuels pour les paquets

Vous pouvez, si vous le souhaitez, séparer les définitions de vos paquets dans des fichiers individuels. Créez un répertoire packages dans le même emplacement que le fichier wpkg.js. Dans ce répertoire, vous pouvez créer des fichiers XML individuels (ex: thunderbird.xml, firefox.xml, etc...). La syntaxe reste la même que dans le fichier packages.xml.

A noter que si vous préferez les fichiers XML individuels de définition de vos paquets, vous devez tout de même garder un fichier packages.xml. Ce fichier doit contenir au moins une entrée vide comme dans l'exemple suivant:

<packages>
</packages>

If you would rather keep your package XML description in separate files, you can of course do it: just create a packages directory where wpkg.js is, and place individual XML files there (i.e., thunderbird.xml, firefox.xml etc.). The syntax is the same as that of packages.xml.

Note, if you decide to keep all your packages in separate XML files, still, you need to have packages.xml file. It should at least contain an empty entry:

<packages>
</packages>

Voir aussi

• profiles.xml:French - définit les profils.
• hosts.xml:French - défines les hôtes.
• wpkg.js:French - Moteur WPKG.
• package dependencies - dépendances de paquets.