http://bugzilla.wpkg.org/show_bug.cgi?id=77
--- Comment #7 from Rainer Meier <[EMAIL PROTECTED]> 2007-10-26 16:06:53 --- Well, thanks Falko for the split up. You probably know the situation. You're trying to analyze the code and while reading it you see lots of things you would change for better readability or to get rid of unused lines of code, or add comments... ao I just did it. Finally I ended up with lots of changes which makes it hard to recognize the real fixes. I did not review your "single files" yet since I think all the changes I made are valid and will work quite well but your files might help to analyze my changes. About http://bugzilla.wpkg.org/show_bug.cgi?id=28 I just read the description and it looks a bit strange to me since the getAllPackages() according to the description creates an array of all packages (installed and available) but the actual function code within 0.9.12-test2 did not merge the "installed packages" array so it was a simple copy of the available packages from packages.xml. I see that the purpose of the change within bug 28 was to skip removal of packages which are within a profile but do not exist in any packages.xml file. However I am using WPKG_WEB where this is not possible. If I remove a package from the package definition (packages.xml) then it disappears from the profile immediately. So it's not possible to have packages within profiles.xml which do not exist within packages.xml. getAvailablePackages(): Returns a list of packages available in any profile. But only packages which are available within packages.xml - if a given package is not within packages.xml it is not returned (I did not behavior). getInstalledPackages(): Returns an array of all installed packages (from local wpkg.xml). I introduced this method since "settings.*" was used several times within the code. getAllPackages() returns a list of all packages within packages.xml (even if not in a profile). The documentation claimed also to include the packages from wpkg.xml (settings node) but did not actually merge it. So I removed the unused code. My new synchronizeProfile() method will do the following algorithm: 1. Use getAvailablePackages() to get all packages from the current profile including dependency profiles but excluding the packages not within packages.xml (note that I did not change the behavior of getAvailablePackages()) 2. get a list of installed packages (locally, within wpkg.xml) 3. check for each installed package (setp 2) if it is present within the available packages from step 1. And mark unavailable ones for removal. 4. Remove all marked packages from the local installation. 5. removePackage() tries to uninstall the package. In case the uninstall string fails it will check if the package is a zombie. Zombie in this case means that the package does NOT exist in packages.xml at all. Step 3 will mark "stale" packages (referenced within the profile but not existing within packages.xml) for removal due to the fact that getAvailablePackages() does not return packages which do not exist within packages.xml. In fact it cannot at all since getAvailablePackages() returns a list of package nodes, not an array of package names but the package node is not available if the package is missing from packages.xml. But this is not a change of me but has been there within 0.9.12-test2 already. So this version seems to be broken in terms of Bug 28 already. I agree that step 5 does not comply to Bug 28 either since it does not take into account packages referenced by the profile but just the pure existence within packages.xml. So to make my changes fully compliant to Bug 28 I propose the following: 1. Modify getAvailablePackages() to return also packages which are referenced by the profile but do not exist within packages.xml. However I strongly recommend not to do this due to the following reasons: - If such a "stale" package (referenced within profile, inexisting within packages.xml) has dependencies the cannot be resolved since profiles.xml does not contain these dependencies. As a result the dependencies will still be missing in the list of "available" packages and therefore marked for removal. This creates even a larger mess on the system. - All the code using the output of getAvailablePackages() will have to be re-written since it will be able to return the package names (ID) only and not the full package node. This is due to the fact thtat the package XML node is only available within packages.xml and in case the profile refers to an inexisting entry within packages.xml this node is not available. So only the package name remains. 2. Change isZombie() to verify if a package is NEITHER listed within packages.xml NOR within any applying profiles. This could be done by iterating through all packages from the modified getAvailablePackages() (see above). So the fixes could be done quite easily by mainly fixing the existing getAvailablePackages() method. It just needs to return another data type (package id instead of package node). However I still strongly vote against doing that since due to the missing package.xml entry packages which are referenced through a dependency of such a "stale" package will be lost and therefore removed. Therefore I recommend keeping the current algorithm to uninstall each package for which no definition within package.xml exists. I am strictly against the wish that wpkg.js should start to fix inconsistencies between profiles.xml and packages.xml. It can happen quite often that somebody deletes a package from packages.xml but but forgets to update one of the profiles. However from my point of view it is the intention of the system administrator to uninstall _ANY_ instance of this package if he removes it from packages.xml. If I could I would even remove such invalid pointers automatically from profiles.xml. In fact wpkg_web does this for you automatically by keeping a consistent database. Again: A deleted package should not appear in any profile. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ wpkg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wpkg-users
