[pacman-dev] [patch] alpm_removedeps bug+fix && alpm_depcmp-discussion
Xavier
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
> here.
>
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 :
http://bugs.archlinux.org/task/3241
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
mailing list