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

[Rainer Meier]

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