[wpkg-users] Empty remove command

Tue Nov 22 11:53:40 CET 2011

After re-reading the "How to remove the package but leave the software installed" thread, I was thinking of another solution for my Dynamics AX updates, let's see if that's possible :

What if I had 2 "checks that verify if software is installed" (although not an install check :P) : one that is the real registry uninstall (or file version check in my case) and the other one being a 'fake' text file exists, with a logical AND between the 2.
So in my install commands, I install the update and create the text file, making the AND between the 2 conditions true and still making sure the update was applied correctly.
In my remove command, I remove just the text file, making the AND between the 2 conditions false so making the software appear 'not installed' to WPKG.

Ideally I would like to retain the ability to use the same package for 32 and 64bits computers so my conditions would be :
"exe file version" AND "text file" in "Program Files" for x86 systems
OR
"exe file version" AND "text file" in "Program Files(x86)" for x64 systems
Is that possible ? It says in the documentation that you can have one or several conditions but is it a OR or an AND between them or can I use a logical condition inside another logical condition ?

Jonathan Verdeyen
IT Engineer

Automatic Systems S.A. - Avenue Mercator, 5 - 1300 Wavre - Belgique
Phone: +32 (0)10 23 02 97 - Fax : +32 (0)10 23 02 02
www.automatic-systems.com

Please consider your environmental responsibility before printing this e-mail.

-----Message d'origine-----
De : Rainer Meier [mailto:r.meier at wpkg.org]
Envoyé : lundi 21 novembre 2011 20:19
À : VERDEYEN Jonathan
Cc : wpkg-users at lists.wpkg.org
Objet : Re: [wpkg-users] Empty remove command

Hi Jonathan,

On 21.11.2011 12:33, VERDEYEN Jonathan wrote:
> I am setting-up WPKG for our company and have cases where I have empty remove
> commands which seems to be a problem when I remove packages as it will think the
> uninstall failed when doing the install checks.

WPKG does not have something which is called "install checks". WPKG just uses
"checks" which are used to verify that a software is installed. If checks return
true WPKG knows the software is installed. If it returns false, then the
software is obviously not installed.

So just make sure your remove commands make sure any of the checks defined fails.

> As I saw in an old thread having empty remove commands should allow to remove a
> package without uninstalling the software, I guess the install check on remove
> is something new and it is a good thing but I don't know how to handle these 2
> cases :

Sure, not specifying uninstall commands will make WPKG just do do nothing on
uninstall. But then WPKG will still execute the checks to see whether the
software is still installed. And of course it is supposed to complain if the
software is still there.

So WPKG will try over and over again to uninstall unless you fix this problem by
fixing your broken package (package is broken if it specifies that nothing has
to be done for uninstall but checks are defined which still yield true after
uninstall).

WPKG has also a feature called zombie detection. When you delete a package
entirely from the server side then WPKG will still remove the package definition
from wpkg.xml even if uninstall fails (checks still true after executing remove
commands). But this is an exceptional case which should not be manually triggered.

> 1°) Software that depends on Microsoft updates/software :
>
> Our ERP software (Dynamics AX 2009) needs .NET Framework so I created (copied) a
> package for it and had the Dynamics AX package depend on it.
>
> But in case I remove the Dynamics AX package from the profile, I would rather
> not have .NET Framework uninstalled.

Why not? If it's not used by any other software?
Well, if you would like to keep it just assign the .NET framework directly to
the profile as well. So after uninstalling Dynamics AX it will leave .NET there.

Alternatively bundle .NET with Dyamics AX and provide checks which verify
installation of Dynamicx AX only. When removing just provide remove commands
which remove Dymanics AX and leave .NET there. So WPKG won't even know about
.NET in this case.

> I guess for this particular case I could just put it in a "Base" profile and
> have it apply to all computers or is there another way ?

Yes. Or bundle it so WPKG won't even know about the fact that Dynamics AX
installs .NET. When removed .NET might remain on the system. WPKG won't care.

> 2°) Dynamics AX 2009
>
> Dynamics AX 2009 has a base installation and then you have to apply updates on
> each computer (no slipstream) and those updates might be individual hotfixes or
> a cumulative service pack/rollup packages.
>
> So right now we have to install Release 1/RTM, then SP1, then SP1 Rollup 7 but
> could later have to add a hotfix, but maybe even later it will be replaced by a
> service pack 2 or another rollup that has to be applied to SP1.
>
> So I created packages for the base install and another one for each update as it
> would allow to check the version and only apply the necessary patches to a not
> up-to-date computer (although whenever we update, we make sure to update all the
> computers) and not reapply patches that were already installed.
>
> In my profile I actually apply only the last update which depends on the
> previous update, which depends on the base package (which depends on .net).
>
> But of course, you can't uninstall the updates, if you uninstall, you uninstall
> the whole software, so I have the remove commands in the base package and no
> remove commands in the update packages (as I said, we might have the case that
> an update is not necessary anymore because it's replaced by a service pack or
> rollup, it has happened before so I want to be ready for it).
>
> I thought it all made sense but my problem is when I remove the package from the
> profile, it will try to uninstall the last update and fail as the install checks
> succeed and stop proceeding to any further uninstall as it couldn't uninstall
> the dependent package.
>
> In the end, I think there should be an option to remove a package without
> uninstalling the software, or is there already ?

Well, yes, in this case you might just omit the remove commands. I would
recommend also to omit the checks, so WPKG will "assume" that on remove (which
actually performs no command at all) is successful and remove it from wpkg.xml.

If you define checks and remove commands, then there is only one way to tell
WPKG not to perform a required uninstall: Use the /noremove command.

Although you might solve the whole problem differently. I am sorry if it does
not work in your case, I might have missed some detail:
Usually I would just maintain one single "Dynamics AX Updates" package. Then
simply specify all the required updates to be applied in order.
Later on when there are new updates, then just add additional commands to the
install and upgrade command list and increment the reivsion. So all your clients
will apply the updates again. In most cases such updates terminate quickly if
they are already applied. So if you have something like 10 commands for most
applications it's allowed just to re-apply the updates in order. If this is not
the case for your application, then using WPKG 1.2.1 release candidates would
allow you to define conditions for each single command; so you can prevent to
re-execute them by specifying appropriate checks.

Example:
<package id='App-Updates' name='Application Updates' revision='1'>
   <check type='uninstall' condition='exists' path='App update 1' />

   <install cmd='msiexec /i /qn ...\path\to\update-1.msi' />

   <remove cmd='msiexec /x /qn ...\path\to\update-1.msi' />

   <upgrade cmd='msiexec /i /qn ...\path\to\update-1.msi' />
</package>

After adding a couple of updates:

<package id='App-Updates' name='Application Updates' revision='5'>
   <check type='uninstall' condition='exists' path='App update 5' />

   <install cmd='msiexec /i /qn ...\path\to\update-1.msi' />
   <install cmd='msiexec /i /qn ...\path\to\update-2.msi' />
   <install cmd='msiexec /i /qn ...\path\to\update-3.msi' />
   <install cmd='msiexec /i /qn ...\path\to\update-4.msi' />
   <install cmd='msiexec /i /qn ...\path\to\update-5.msi' />

   <remove cmd='msiexec /x /qn ...\path\to\update-1.msi' />
   <remove cmd='msiexec /x /qn ...\path\to\update-2.msi' />
   <remove cmd='msiexec /x /qn ...\path\to\update-3.msi' />
   <remove cmd='msiexec /x /qn ...\path\to\update-4.msi' />
   <remove cmd='msiexec /x /qn ...\path\to\update-5.msi' />

   <upgrade cmd='msiexec /i /qn ...\path\to\update-1.msi' />
   <upgrade cmd='msiexec /i /qn ...\path\to\update-2.msi' />
   <upgrade cmd='msiexec /i /qn ...\path\to\update-3.msi' />
   <upgrade cmd='msiexec /i /qn ...\path\to\update-4.msi' />
   <upgrade cmd='msiexec /i /qn ...\path\to\update-5.msi' />
</package>

Then apply a service pack instead:

<package id='App-Updates' name='Application Updates' revision='6'>
   <check type='uninstall' condition='exists' path='App SP1' />

   <install cmd='msiexec /i /qn ...\path\to\sp1.msi' />

   <remove cmd='msiexec /x /qn ...\path\to\sp1.msi' />

   <upgrade cmd='msiexec /i /qn ...\path\to\sp1.msi' />
</package>

Just a side note... If you decide at any point in the future that you would like
to remove the "App-Updates" package from all your nodes without actually
performing any change on the nodes, then just update your package definition and
remove the package from the profile:

<package id='App-Updates' name='Application Updates' revision='7'>
</package>

I did not test this yet since I don't have my test environment right at my
fingertips now. But The upgraded revision shall make it upgrade. As there is no
command specified the upgrade won't perform any change on the system. Then WPKG
will remove the package (as you remove it from the profile). The remove will
succeed (no commands, no checks) and WPKG shall remove the package from wpkg.xml.

Alternatively a dummy package as follows shall work too:

<package id='App-Updates' name='Application Updates' revision='7'>
   <check type='file' condition='exists' path='%ProgramFiles%\app.txt' />

   <install cmd='%COMSPEC% /c echo 1 > "%ProgramFiles%\app.txt"' />

   <remove cmd='%COMSPEC% /c del /f /q "%ProgramFiles%\app.txt"' />

   <upgrade cmd='%COMSPEC% /c echo 1 > "%ProgramFiles%\app.txt"' />
</package>

This would tell WPKG that the update to be performed for this package performs
the creation of a dummy file. The update of course will succeed. After the
update WPKG is going to remove the package which removes the dummy file and
since remove succeeded WPKG will remove "App-Updates" from wpkg.xml.

In this case you won't even execute any remove commands since the package with
the purpose to update your application to the latest version is always the same
package - just updated with new patches.

br,
Rainer

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

Ce message et toutes les pièces jointes (ci-après le "message") sont confidentiels et établis à l'intention exclusive
de ses destinataires. Toute utilisation ou diffusion non autorisée est interdite. Si vous n'êtes pas destinataire de ce
message, merci de le détruire immédiatement et d'avertir l'expéditeur.
--> Pensez à l'environnement avant d'imprimer ce message.

This message and any attachments (the "message") are confidential and intended solely for the addressees.
Any unauthorised use or dissemination is prohibited. If you are not the intended addressee of this message,
please delete it immediately and inform the sender.
--> Please consider the environment before printing this email.

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________