[pacman-dev] do we need requiredby?

[Xavier]

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.