On Mon, Nov 12, 2007 at 05:21:31PM +0100, Nagy Gabor wrote:
What's more, this is not a speed-up at all! So I'm pretty sure now, that storing requiredby is _useless_ (no, even worse: a bug generator): I simply forgot about update_requiredby! Requiredby is computed when the package was born on localdb <- requiredby computation is ~exactly 4./b.). This result is used only in the following cases: *) by pacman: -Si and -Qi (wow), --orphan *) deps.c/checkdeps && can_remove *) libalpm/sync.c:566,1256 what are these?! we don't copy requiredby fields on package upgrade neither, why should we copy it between to-be-replaced and replacer?! [And I didn't say anything about trans_update_depends, grr.] Summary: if we just simply followed 4./b.), we would compute requiredby on package death instead of on package born. The question is: how many times we use this information without removal (-Qi, -Si and can_remove, --orphan). But as testdb shows: compute requiredby for _all_ packages is not costly at all.
So I will create a patch for killing requiredby soon. The patched pacman will be compatible with the old dbs; however, old pacmans with new dbs will fail. What do you say? Any contras? [my patch would simulate alpm_pkg_get_requiredby with compute_requiredby]
I think you are right, but if performance was your original goal, it seems like you are always going in the opposite direction :) Though, I totally agree that a poor implementation of requiredby only have drawbacks : * more complexity * more bugs * no speed up I wouldn't be surprised if removing requiredby didn't cause any slow downs, but better check it anyway if you do remove it :) About the last compatibility problem, I don't see it as a big one, but I could be wrong.