[pacman-dev] [PATCH] Reduce the negligence of _alpm_resolvedeps
ngaba at bibl.u-szeged.hu
Fri Nov 30 15:13:23 EST 2007
> On Fri, Nov 30, 2007 at 08:39:22PM +0100, Nagy Gabor wrote:
> > > OK, but I leave the benchmark for you;-)
> > > Note: Long "dependency paths" like in smoke001.py may cause
> > > notable slowdown.
> > > I made a quick "hack", so probably I made some mistakes...
> > >
> > > Bye
> > Well, resolvedeps is also quite hard to read (but seems OK).
> > Imho we should share some code between alpm_sync_addtarget and
> > resolvedeps: I mean they could use common search_for_literal(),
> > search_for_satisfier() functions. By doing this alpm_resolvedeps
> > would be much clearer and '-S provision' would be more general,
> > user could do -S 'depend>=2.0' if he wants to do so (he got an
> > unsatisfied dependency error after -A) and we can slowly kill
> > whatprovides... (foo provides bar is a special case of foo
> > satisfies bar)
> On this subject, see http://bugs.archlinux.org/task/8763 .
Well, I wanted to ask this earlier: is it possible (and acceptable) to
"forward" pacman FS activity to here automatically? (/me never reads FS)
Back to 8763: Imho this is a bit off here. But my opinion hasn't changed
since -Sg: user should know and define what he wants to do. So my vote:
"-S literal" only, if this wasn't successful, pacman can ask the user
whether he wants to search for providers etc... And a special option to
install provider (or satisfier).
More information about the pacman-dev