Hi Paul,
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
---------------------------------
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/