[wpkg-users] removing a package dependency has uninstalled that first package from all clients and then reinstalled

[Paul McGrath]

Hi Rainer,
  Thank you for the extensive explanation.  I understand all your logic and after consideration I think I did the increment version when removing a dependency before avoiding this problem I had today.  I will document this locally so I don't make the same mistake again.  Bit of a pain when 700 computers all try and reinstall SPSS over a few hours :-)

I was bad package naming and a throw back to 10 years worth of WPKG packages.  My old packages were usually version named dotnet11 which I moved away from.

Thanks again
Paul

-----Original Message-----
From: Rainer Meier [mailto:r.meier at wpkg.org] 
Sent: 30 November 2016 21:35
To: Paul McGrath <J.P.McGrath at leeds.ac.uk>; wpkg-users at lists.wpkg.org
Subject: Re: [wpkg-users] removing a package dependency has uninstalled that first package from all clients and then reinstalled

Hi Paul,

On 30.11.2016 12:22, Paul McGrath wrote:
> I've a bit of a problem this morning.
>
> Yesterday I removed an old .Net package as a dependency of a Visual C
> 2008 redistributable.
>
>  This morning all packages that depend on VC2008 are currently 
> uninstalling and reinstalling.  Essentially a dependency of a 
> dependency has resulted in all my clients uninstalling software.
>
> Why is it configured to do this?  It shouldn't be necessary.


OK, this is a bit more difficult to explain but actually is a logical result of WPKG dependency handling. Let me try to explain:

1. WPKG evaluates the package database on server side, .NET is removed from this package tree.

2. WPKG makes a decision which packages to be removed during the process. As .NET is missing from the dependency tree defined on server-side it schedules .NET for removal.
Up to now it's pretty easy to follow I guess.

3. Now WPKG tries to assure a consistent system state by first performing all uninstall actions (packages removed from the dependency/profile tree) and then verify all remaining packages by assuring they are all installed (checking each of them).

During this process now WPKG first schedules .NET to be removed. As WPKG knows your VC2008 package depends on the .NET package it will also remove VC2008 temporary. Unfortunately in your case many other packages depend on VC2008 which is uninstalled now and as of consistency reasons WPKG first removes also all packages depending on VC2008 first.

The good thing about this is now that after removing .NET and the complete dependency chain WPKG will proceed and verify all packages and therefore re-install VC2008 and also all packages depending on it.

So after the complete action (which unfortunately will re-install many
packages) you should end up in a consistent system.

---

Now let's think about how to resolve this:

You might think about upgrade-before-remove feature. But this does not help here as the offending VC2008 package is not scheduled for direct removal but gets removed only by dependency resolution on .NET package.

So of course WPKG could be changed to first do the upgrade/install/verification process first and the removals last. This allows WPKG to re-evaluate the local package tree before the removal and since VC2008 package has been upgraded it would first upgrade it and therefore lose any connection to the .NET package and allow to remove .NET without removing anything else.

This however includes a potential risk. The risk is if you would have removed the dependency from the VC2008 package WITHOUT incrementing the
VC2008 package revision attribute. In such case WPKG would proceed with the install/upgrade verification and perform no changes to the VC2008 package (revision not changed). Then in last step of package synchronization it would go for the removal of .NET and its dependencies. As VC2008 was not updated it would remove VC2008 and also its dependencies (all other packages) and then terminate. This would leave your clients in a state where all packages are removed, but not re-installed.

The only work-around for this I see would be to verify the install state before AND after the removal process which would in the case depicted above result in the same situation as you are seeing it (packages verified, removing all of them, re-installing all of them). However it would require WPKG architecture changes and would have a serious performance impact as all packages would be processed twice for installation/verification (before and after removal process).


So I agree that changing the order of package processing would solve your issue with the risk of leaving the system in incomplete state if
VC2008 was improperly changed (dependency modified, revision not changed). With the current algorithm it might lead to unexpected re-installs but after synchronization you are left with a consistent system in any case (.NET removed, VC2008 and all packages depending on it re-installed).


---

As a result I am currently a bit unsure what to do. I have tested the dependency handling with swapped order (install/verify/upgrade first and then remove) which works in most cases but in some special cases might leave you with a broken system - this might be fixed easily by running wpkg again (i.e. rebooting the node) but still could leave you with a broken system after WPKG run.

In the order implemented currently the system will perhaps perform unnecessary install/uninstall but assures proper system state in any case which was actually the goal during installation. But I see it's perhaps an issue in your case as you cannot properly remove the dependency in one step.
The only "clean way of removing the dependency without reinstalls would be:
- Upgrade VC2008 package revision removing dependency from the package
- Insert .NET package directly in profile dependency to avoid immediate removal
- After all clients applied the upgrade you can safely remove the .NET package from the profile

I know this is not very clean and does not allow you to remove the .NET package easily. But it assures proper system state at any stage.


So currently I am more in favor of keeping the current algorithm in 
place, even if it could lead to some unexpected re-installs in very 
specific cases but it assures proper system state and in case of proper 
packaging removal/reinstall should work properly at the cost of higher 
overhead in this special case.


let me know your opinion

Rainer