[pacman-dev] do we need requiredby?
Dan McGee
dpmcgee at gmail.com
Mon Nov 12 16:35:00 EST 2007
On Nov 12, 2007 2:28 PM, Aaron Griffin <aaronmgriffin at gmail.com> wrote:
> On Nov 12, 2007 2:18 PM, Travis Willard <travis at archlinux.org> wrote:
> > On Mon, 12 Nov 2007 14:08:07 -0600, Aaron Griffin wrote
> > > 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.
> > >
> > > 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).
> > > 2) Our package structures will shrink in size, which is always good
> >
> > 3) Computing requiredby every time will ensure (if the computation is done
> > right) that requiredby will always be correct. Even after -Rd operations
> > followed by subsequent -S operations and other crazy things. Basically, less
> > bookkeeping to do on install/remove.
>
> I knew I had more points in my head! This was one of them - preventing
> DB corruption.
>
> 4) Less disk writes, as we actually have to write, compute, and
> rewrite the entry, if memory serves me correctly.
+1. I think we can trade a possible slight performance loss in a few
cases for all the things mentioned above. I also think it will cut out
a lot of crappy code.
Throwing the project manager speak into this here- it isn't getting
into 3.1. This will be a great kickoff for 3.2 major changes though.
-Dan
More information about the pacman-dev
mailing list