[wpkg-users] Empty remove command

[Rainer Meier]

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