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 ------------------------------------------------------------------------- wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/ _______________________________________________ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
