[wpkg-users] Removing a dependency, removes all packages in the dependency chain

[Rainer Meier]

Hi Daniel,

On 08.06.2010 09:41, Daniel Dehennin wrote:
> To be really clear, if a dependency is removed, it's normal to remove
> the depending package (it's not supposed to work without it's
> dependency), but it may not do so if this one is in upgrade (which may
> remove the dependency) ?

You are right. This might be the actual reason for the confusion.

WPKG first performs all removes. Since Pidgin was the only package referring to
the GTK package it is put to the remove list when Pidgin does not refer to it
any more. As a result all packages depending on GTK (Pidgin at time of remove of
GTK) will be removed in advance.

To prevent this WPKG could do package removal after all upgrade/downgrade
actions. But this has some other drawbacks (even worse from my point of view):
- If packages installed detect that one of the packages which will be removed
later exists they might enable some functionality which will not work due to
immediate following removal of this package.
- Remove will depend on success of previous install/upgrade/downgrade. If one of
the installation packages fail then remove has to be aborted.


Alternatively I thought about making the remove procedure more smart to detect
if a package which depends on the one to be removed removes this dependency on
upgrade. Unfortunately this information is not yet available to the remove
procedure. Further more this would mix a bit the remove and
install/upgrade/downgrade commands which are currently executed strictly
sequentially.


Another possibility which might work is to exclude any package from the initial
remove procedure which is referred by any dependency statement either in the old
or within the new package tree. The reason is that during the remove list
creation we don't know yet if this dependency will still be needed or not after
the upgrade. This will make WPKG to remove only the packages which are not
referenced by any other package at this step.
WPKG might then do a second "cleanup" step right after all
installs/upgrades/downgrades finished just to remove packages which are obsolete
at this point in time. This should include orphaned dependencies which are not
needed any more.

Unfortunately this still does not make sure that (referring to the example) GTK
is removed before the new version of Pidgin is installed. In worst case this
would make the installer of Pidgin depending on the GTK package installed on the
system. Well, I don't think this is the case with Pidgin but there might be
applications behaving like this.


Another solution might be just to disable the remove of dependent packages
during the synchronization procedure. In theory comparing the package trees
(current packages vs. new packages) should list all packages not used any more
independently. In our example it should list Pidgin in both trees but GTK only
in the current tree. So removing GTK without touching Pidgin would be safe.
Unfortunately it will leave you with a broken Pidgin installation if the upgrade
later on fails. This is due to the fact that the old Pidgin which will still be
in place will miss its GTK installation then (which can even not be re-installed
since it's expected to be removed from the server already).
But this might be the easiest way to do it which allows keeping dependent
packages even if dependencies are removed. Unfortunately I believe that this way
of doing it is not really the clean way because it will allow an unclean system
state: Dependency removed but package requiring it still installed.



So personally I currently still think that the current behavior (removing GTK
and therefore the old Pidgin) prior to installing the new Pidgin version is
entirely correct and the most safe way to do it.
Another "artificial" example of this could be an application bundled with JRE.
Let's assume you put a dependency on your JRE package for old versions and the
new version only offers a bundled version which includes JRE itself. However the
installer might detect during installation if there is a suitable JRE installed
on the system and use this one instead. In such case the correct migration from
the old to the new version is in fact:
- Remove old application version because JRE dependency is uninstalled
- Remove JRE (assuming it's not referred by any other application)
- Re-install bundled application


I am sorry about this longish and probably chaotic message. I was thinking about
possible ways to improve the situation for about an hour and continuously
updated, dadded and deleted the message while I was trying to think about the
whole impact of such a change. Unfortunately my conclusion finally was the
statement above; I think the way WPKG is handling it currently might be
unexpected but it makes sure the system state is consistently maintained at any
point in time.



By the way, the problem encountered by you (missing remove.cmd) during upgrade
since you removed it from the server is always a problem. And I think you should
revise your server retention policy or the package structure. Remember that WPGK
is designed to handle hosts which can have any state at any point in time. So
maybe you removed package X several months ago but there is a laptop connecting
to your network only once a year. So this laptop will probably try to remove a
package very late when you already removed it from your package database. So the
only way to provide full consistency is to keep your install/remove scripts on
the server unless you're fully sure no package is deployed on any node which
still refers to it. In your case you broke that rule by removing this Pidgin
2.6.6 "remove.cmd" file which is referred by any wpkg.xml on any node running
Pidgin 2.6.6.
Disk space nowadays is not so expensive any more which should not enforce you to
delete all previous packages immediately. Personally I prefer to keep 1 to 3
previous versions on the server. As I know all my hosts connect at least once
per week to the network this is entirely sufficient for my use case.
If you really want to remove the package software from the server you should
consider copying scripts like "remove.cmd" to the local hard drive to allow
clients uninstalling the package autonomously - or just put all commands
included in "remove.cmd" into the package definition (which is stored locally in
wpgk.xml too).


br,
Rainer