[pacman-dev] do we need requiredby?

[Nagy Gabor]

> On Nov 12, 2007 10:21 AM, Nagy Gabor <ngaba at bibl.u-szeged.hu> wrote:
> > 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]
> 
> Just to make sure I understand you - you want to fully remove
> REQUIREDBY from the DB and compute it every time.
Exactly.

> It will be a little slower, BUT, it will help us in a few ways:
> 
> 1) we don't need REQUIREDBY all that often. It's only used in removal,
> and replace functionality if I understand correctly. The performance
> hit will not be that big in this case (removal happens far less often
> than addition).
Note: upgrade is also a "replace"; so we must compute requiredby in this case,
too. But this is also done now; just not in the removal part: this is done in
the add part (now every package addition also induces a compute_requiredby... +
alpm_trans_update_depends, so even a bit more).
So requiredby is _computed_ now on foo package born (and some not notable
modifications happens if new "requiredby" packages are installed). So we waste
time for computing requiredby, iff the package won't be removed (depcheck error,
-Si, -Qi, --orphan), because in the package "life" we do this computation more
than once (on removal, we _will_ compute).
As I see, the effects in speed will be (we are talking about just seconds here):
-add_prepare won't change, add_commit will be faster
-remove_prepare will be slower, remove_commit won't change, so user must wait
longer for checkdeps errors and confirmation questions (negative impact) 
-so -A will be faster, -R will be slower than now
- -U/-S: prepare will be slower (effect of ~remove_prepare), commit will be
faster (effect of add_commit), so user must wait longer for checkdeps errors and
confirmation questions (negative impact); but overall it will be faster (because
usually more package-adding than package-removal happens here)

> 2) Our package structures will shrink in size, which is always good
> 
> I say go for it. Sounds like a pretty decent idea if I'm understanding
> you correctly. As usual, I await your patches 8)
OK.
Bye, ngaba


----------------------------------------------------
SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu
This mail sent through IMP: http://horde.org/imp/