[pacman-dev] [patch] alpm_removedeps bug+fix && alpm_depcmp-discussion
shiningxc at gmail.com
Mon Jun 18 13:35:28 EDT 2007
2007/6/18, Dan McGee <dpmcgee at gmail.com>:
> On 6/18/07, ngaba at petra.hos.u-szeged.hu <ngaba at petra.hos.u-szeged.hu> wrote:
> > Hi!
> > I attached the pactest file and my patch. I also made some
> > modifications in alpm_removedeps' args, because the old one was a bit
> > messy for me. And I think that my version is faster.
> > can_remove_package is a bit stupid (compared to alpm_checkdeps), but I
> > leave it untouched, because speed is more important here than
> > "perfection".
> IMO, doing things right is what we want to do in 99% of the cases this
> speed vs. perfection issue comes up, so I'm going to disagree with you
It looks like checkdeps could indeed be used here.
There is also the install reason which comes into play here though.
This problem was mentioned here :
Aaron didn't see any reason for checking that the packages removed by
-Rs are only dependencies, but I believe there is one, as I tried to
explain in my comment.
> In addition, to assume anything only makes an ass out of u (you) and
> me. I don't want to introduce any functions that depend on a
> particular quirk of our list implementation, especially since this is
> one of the things we have considered changing.
What about just renaming alpm_list_add to alpm_list_add_last ?
That way, there isn't any assumption, it's explicit :)
> I feel that if we look at the bigger picture and stop thinking of add,
> remove, and sync as isolated actions, then we could get some HUGE
> refactoring and code reduction going on with cases like this. However,
> this will be one large undertaking.
There are often several ways to do things right, and we probably don't
all see the same, so it would help if it was a bit more concrete :)
You are probably the only one who can get things exactly like you
want, unless maybe you explain it in details.
More information about the pacman-dev