[pacman-dev] Pacman doesn't handle properly the multiple satisfiers, localdb corruption
Hi! Well, you probably will ask me to send patch, but I'm waiting for your decision. First, here is the problem: ===requiredby005.py== self.description = "Remove lp1, requiredby should move from lp1 to lp2" lp1 = pmpkg("foo") lp1.requiredby = ["pkg3"] self.addpkg2db("local", lp1) lp2 = pmpkg("pkg2") lp2.provides = ["foo"] self.addpkg2db("local", lp2) lp3 = pmpkg("pkg3") lp3.depends = ["foo"] self.addpkg2db("local", lp3) self.args = "-R %s" % lp1.name self.addrule("PACMAN_RETCODE=0") self.addrule("!PKG_EXIST=foo") self.addrule("PKG_EXIST=pkg2") self.addrule("PKG_REQUIREDBY=pkg2|pkg3") ------------------------- This test fails and hence the database becomes corrupt: alpm_checkdeps is clever enough to let pacman remove foo, however update of pkg2's requiredby is missing after the remove. However, this is not a pactest to commit: as you see, pkg2's requiredby field is missing: this can happen, if pkg3 was the last installed package, because _alpm_trans_update_depends works in a "funny" way: it fills in the "literal" satisfier's requiredby only or _all_ "provider" satisfiers' requiredby. So, my question, how I fix this? How should we store multiple satisfiers in localdb? case 1: We find all satisfier package and fill in _all_ requiredby fields. case 2: We flag only one package as a satisfier with requiredby, and we handle properly these requiredby "moves". case 3: any other idea? We must choose one, because this is not defined in pacman now. I prefer case 1. Pros: -easy to implement (only _alpm_trans_update_depends needs patching) -by doing this, we clean up _alpm_trans_update_depends using alpm_depcmp -_alpm_pkg_update_requiredby prefers this way now -this won't break prepare/commit hierarchy (because alpm_checkdeps should somehow inform remove_commit in case 2) -when using -d switch, implement case 2 is difficult Contras: -slower!! (we need to check for providers always) -some users may have corrupted(?) localdb as shown in the pactest file (this is rare) -one satisfier is enough Bye, ngaba ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On Mon, Jul 16, 2007 at 11:43:38AM +0200, ngaba@petra.hos.u-szeged.hu wrote:
Hi!
Well, you probably will ask me to send patch, but I'm waiting for your decision. First, here is the problem: ===requiredby005.py== self.description = "Remove lp1, requiredby should move from lp1 to lp2"
lp1 = pmpkg("foo") lp1.requiredby = ["pkg3"] self.addpkg2db("local", lp1)
lp2 = pmpkg("pkg2") lp2.provides = ["foo"] self.addpkg2db("local", lp2)
lp3 = pmpkg("pkg3") lp3.depends = ["foo"] self.addpkg2db("local", lp3)
self.args = "-R %s" % lp1.name
self.addrule("PACMAN_RETCODE=0") self.addrule("!PKG_EXIST=foo") self.addrule("PKG_EXIST=pkg2") self.addrule("PKG_REQUIREDBY=pkg2|pkg3") ------------------------- This test fails and hence the database becomes corrupt: alpm_checkdeps is clever enough to let pacman remove foo, however update of pkg2's requiredby is missing after the remove. However, this is not a pactest to commit: as you see, pkg2's requiredby field is missing: this can happen, if pkg3 was the last installed package, because _alpm_trans_update_depends works in a "funny" way: it fills in the "literal" satisfier's requiredby only or _all_ "provider" satisfiers' requiredby. So, my question, how I fix this? How should we store multiple satisfiers in localdb? case 1: We find all satisfier package and fill in _all_ requiredby fields. case 2: We flag only one package as a satisfier with requiredby, and we handle properly these requiredby "moves". case 3: any other idea? We must choose one, because this is not defined in pacman now. I prefer case 1. Pros: -easy to implement (only _alpm_trans_update_depends needs patching) -by doing this, we clean up _alpm_trans_update_depends using alpm_depcmp -_alpm_pkg_update_requiredby prefers this way now -this won't break prepare/commit hierarchy (because alpm_checkdeps should somehow inform remove_commit in case 2) -when using -d switch, implement case 2 is difficult Contras: -slower!! (we need to check for providers always) -some users may have corrupted(?) localdb as shown in the pactest file (this is rare) -one satisfier is enough
Oh yes, please, clean that update_depends function, trying to read it almost killed me. (so go with case 1 I guess). About corrupted db, most db are already corrupted, but in a less important way : extra required by field (fixed by your upgraderm patch), instead of missing required by fields as it's the case here. But so, couldn't we have an option in pacman for repairing requiredby fields or something ?
About corrupted db, most db are already corrupted, but in a less important way : extra required by field (fixed by your upgraderm patch), instead of missing required by fields as it's the case here. But so, couldn't we have an option in pacman for repairing requiredby fields or something ? Well, in the future alpm_db_test should do a deeper db check (and try to fix errors: for example requiredby fields can be generated from depends easily); now it only does very basic "syntax" checking, which is a bit confusing for me (consistency check means more IMHO). Bye, ngaba
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On Mon, Jul 16, 2007 at 04:31:32PM +0200, ngaba@petra.hos.u-szeged.hu wrote:
About corrupted db, most db are already corrupted, but in a less important way : extra required by field (fixed by your upgraderm patch), instead of missing required by fields as it's the case here. But so, couldn't we have an option in pacman for repairing requiredby fields or something ? Well, in the future alpm_db_test should do a deeper db check (and try to fix errors: for example requiredby fields can be generated from depends easily); now it only does very basic "syntax" checking, which is a bit confusing for me (consistency check means more IMHO).
Yes indeed, that's what I was thinking about. Maybe it could also look for broken dependencies also (mostly breakage caused by --nodeps). The problem is I'm not sure it fits perfectly in libalpm. Maybe it should rather be an external tool, using libalpm (in src/util/). That should be enough at least for checking, but for writing to the database in order to correct inconsistencies, I'm not sure..
On Mon, Jul 16, 2007 at 04:47:12PM +0200, Xavier wrote:
Yes indeed, that's what I was thinking about. Maybe it could also look for broken dependencies also (mostly breakage caused by --nodeps). The problem is I'm not sure it fits perfectly in libalpm. Maybe it should rather be an external tool, using libalpm (in src/util/). That should be enough at least for checking, but for writing to the database in order to correct inconsistencies, I'm not sure..
Finally, I think that isn't needed, errors can be corrected by just
reinstalling the packages.
So just displaying the missing dependencies, and extra / missing
requiredby fields should be enough.
I tried putting the code in an external tool (starting from the existing
testpkg.c one), but that's stupid, because that code is already in libalpm.
The dependencies / requiredby handling functions should be refactored a bit
so that it could be used in this case, and then either they should be
exported so that it could be used in an external tool, or there should be a
little function in libalpm for checking for inconsistencies.
I'll still attach the prog as a reference, because I think it might be interesting.
But I really hate the code : copy / pasting is the lazy way, and imo that's one
of the reason the current code base is so ugly and messy.
/*
* testdb.c : Test a pacman local database for validity
*
* Copyright (c) 2007 by Aaron Griffin
Well, I haven't read your code yet (but I will;-); but you could use pseudo packages (created from the db) and use libalpm functions, for example, alpm_checkdeps for dependency checking and _alpm_pkg_update_requiredby (and then a comparison with the db) for requiredby testing; and this would be independent from libalpm version. Bye, ngaba ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On Tue, Jul 17, 2007 at 09:40:02PM +0200, ngaba@petra.hos.u-szeged.hu wrote:
Well, I haven't read your code yet (but I will;-); but you could use pseudo packages (created from the db) and use libalpm functions, for example, alpm_checkdeps for dependency checking and _alpm_pkg_update_requiredby (and then a comparison with the db) for requiredby testing; and this would be independent from libalpm version.
Do you mean the same pseudo target code that was removed : http://www.archlinux.org/pipermail/pacman-dev/2007-July/008911.html ? Or the the same idea but implemented differently ?
Do you mean the same pseudo target code that was removed : http://www.archlinux.org/pipermail/pacman-dev/2007-July/008911.html ? Qoute from that e-mail: "But there is at least one way to do that, it's creating a dummy package, with the same list of dependencies as in the PKGBUILD, and work with that in libalpm." Yes, this is what I said, except we use the db/depends instead of PKGBUILD. Bye, ngaba
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On Wed, Jul 18, 2007 at 02:57:09PM +0200, ngaba@petra.hos.u-szeged.hu wrote:
Do you mean the same pseudo target code that was removed : http://www.archlinux.org/pipermail/pacman-dev/2007-July/008911.html ? Qoute from that e-mail: "But there is at least one way to do that, it's creating a dummy package, with the same list of dependencies as in the PKGBUILD, and work with that in libalpm." Yes, this is what I said, except we use the db/depends instead of PKGBUILD.
Yes, but I was mostly asking about the implementation from Aurelien that was removed. If finally it was ok and it should be added back, or if it should be implemented in another better way.
Yes, but I was mostly asking about the implementation from Aurelien that was removed. If finally it was ok and it should be added back, or if it should be implemented in another better way.
Well, Aurelien's implementation is quite complicated (but maybe fine), I think easier to use alpm_db_get_pkg for dummy package "creation". Bye, ngaba PS: After reading your code, it looks independent from libalpm version (it using alpm_depcmp), so it seems to be perfect ;-) ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On Wed, Jul 18, 2007 at 03:33:07PM +0200, ngaba@petra.hos.u-szeged.hu wrote:
Yes, but I was mostly asking about the implementation from Aurelien that was removed. If finally it was ok and it should be added back, or if it should be implemented in another better way.
Well, Aurelien's implementation is quite complicated (but maybe fine), I think easier to use alpm_db_get_pkg for dummy package "creation".
Bye, ngaba PS: After reading your code, it looks independent from libalpm version (it using alpm_depcmp), so it seems to be perfect ;-)
Hm finally it doesn't seem easy (on the code side) to detect invalid duplicated requiredby entries (after your new update_trans_depends function). For example if pkg1 has pkg2 twice in its requiredby field, while pkg2 satisfy only one dependency of pkg1. We can't just detect for duplicate in requiredby fields anymore, because they might be valid (if pkg2 provided two deps of pkg1). I would need to compute requiredby fields fully for each pkg, and compare to the old one. By calling check_depends(pkg) on all package from the local database, I have enough information for computing all requiredby fields. But the problem is I can't store these. In this part : 139 if(deppkg && alpm_depcmp(deppkg, dep)) { 140 found = 1; I would need to do something like : alpm_list_t *newrqdby = alpm_pkg_get_newrequiredby(deppkg); newrqdby = alpm_list_add(newrqdby, pkgname). And when everything is done, compare old and new requiredby lists for each package. But I don't see any way to do that. (that would also make my check_requiredby() function useless). Or maybe I could achieve the same (in a less efficient way) with a more complicated check_requiredby function. But on the algorithm side, this check_requiredby function is stupid because everything is done by check_depends..
Hm finally it doesn't seem easy (on the code side) to detect invalid duplicated requiredby entries (after your new update_trans_depends function). For example if pkg1 has pkg2 twice in its requiredby field, while pkg2 satisfy only one dependency of pkg1. My patch hasn't been accepted yet ;-) By calling check_depends(pkg) on all package from the local database, I have enough information for computing all requiredby fields. But the problem is I can't store these. So you can use _alpm_trans_update_depends, then compare the result with the db;-) Bye, ngaba
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On Wed, Jul 18, 2007 at 08:20:40PM +0200, ngaba@petra.hos.u-szeged.hu wrote:
Hm finally it doesn't seem easy (on the code side) to detect invalid duplicated requiredby entries (after your new update_trans_depends function). For example if pkg1 has pkg2 twice in its requiredby field, while pkg2 satisfy only one dependency of pkg1. My patch hasn't been accepted yet ;-)
I forgot to answer to this part. Yes indeed, it hasn't been accepted, so it's just in case :)
On Wed, Jul 18, 2007 at 05:23:50PM +0200, Xavier wrote:
By calling check_depends(pkg) on all package from the local database, I have enough information for computing all requiredby fields. But the problem is I can't store these.
In this part : 139 if(deppkg && alpm_depcmp(deppkg, dep)) { 140 found = 1;
I would need to do something like : alpm_list_t *newrqdby = alpm_pkg_get_newrequiredby(deppkg); newrqdby = alpm_list_add(newrqdby, pkgname).
And when everything is done, compare old and new requiredby lists for each package. But I don't see any way to do that. (that would also make my check_requiredby() function useless).
Or maybe I could achieve the same (in a less efficient way) with a more complicated check_requiredby function. But on the algorithm side, this check_requiredby function is stupid because everything is done by check_depends..
Well, here is the original testdb file I already posted, plus the above suggestion implemented (which allows more efficient code + the detection of wrongly duplicated requiredby). But that really sucks of course :( I hate C.. There is really no clean way to do what I want? I guess I could create a new pkg structure type only for that testdb file, for storing the new requiredby field, or having a second local pkgcache (duplicating every package and storing them in a list, and modifying the requiredy field there). But the code is already huge compared to the simple things it does. It would make it even more huge :p I think I'll start learning C# so I can hack on Maelstorm when its released :) Or maybe the best thing here would be to use libalpm bindings with an higher level language.
On Fri, Jul 20, 2007 at 11:09:55PM +0200, Xavier wrote:
But that really sucks of course :( I hate C.. There is really no clean way to do what I want? I guess I could create a new pkg structure type only for that testdb file, for storing the new requiredby field, or having a second local pkgcache (duplicating every package and storing them in a list, and modifying the requiredy field there). But the code is already huge compared to the simple things it does. It would make it even more huge :p
What I would have done in Java is probably using a HashMap. So I did the same in C, I took the implementation of hash tables from there : http://www.cl.cam.ac.uk/~cwc22/hashtable/ and used that instead of my previous newrequiredby hack for storing the new requiredby fields :) The problem is that the hashtable implementation is bigger than the testdb.c file itself.. But couldn't hash tables also be useful for the rest of the code? Having O(1) access to elements instead of the O(n) _alpm_pkg_find() for example could be interesting in some cases in my opinion.
On Sat, Jul 21, 2007 at 11:31:35AM +0200, Xavier wrote:
On Fri, Jul 20, 2007 at 11:09:55PM +0200, Xavier wrote:
But that really sucks of course :( I hate C.. There is really no clean way to do what I want? I guess I could create a new pkg structure type only for that testdb file, for storing the new requiredby field, or having a second local pkgcache (duplicating every package and storing them in a list, and modifying the requiredy field there). But the code is already huge compared to the simple things it does. It would make it even more huge :p
What I would have done in Java is probably using a HashMap. So I did the same in C, I took the implementation of hash tables from there : http://www.cl.cam.ac.uk/~cwc22/hashtable/ and used that instead of my previous newrequiredby hack for storing the new requiredby fields :) The problem is that the hashtable implementation is bigger than the testdb.c file itself..
But couldn't hash tables also be useful for the rest of the code? Having O(1) access to elements instead of the O(n) _alpm_pkg_find() for example could be interesting in some cases in my opinion.
Also found out there was a hash table implementation based on kernel list : http://isis.poly.edu/kulesh/stuff/src/ This does the job as well.
Well, it looks fine; however free(dep) is missing. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On Wed, Jul 18, 2007 at 03:15:53PM +0200, ngaba@petra.hos.u-szeged.hu wrote:
Well, it looks fine; however free(dep) is missing.
Indeed, I corrected that.
participants (2)
-
ngaba＠petra.hos.u-szeged.hu
-
Xavier