[wpkg-users] [Bug 77] Zombie package handling

[bugzilla-daemon at bugzilla.wpkg.org]

http://bugzilla.wpkg.org/show_bug.cgi?id=77





--- Comment #7 from Rainer Meier <skybeam at users.sourceforge.net>  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.


wpkg-users mailing list
wpkg-users at lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users