On 6/18/07, Xavier wrote:

2007/6/18, Dan McGee :

...

On 6/18/07, ngaba@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 :)

This isn't a bad idea, but I'm thinking of changes on a much larger scale. Read here for details: http://isis.poly.edu/kulesh/stuff/src/klist/

...

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.

I agree- and part of this is me NOT trying to enforce my 'right' way on everyone else. Here is how I see our operations-based thinking being reformed a bit. There are two baseline operations- install (add) and remove. upgrade is a combination of an add and remove, and sync is a combination of install, remove, upgrade, and a little extra sugar on the side. Instead of having duplicated code everywhere, we should be able to build up a set of functions that are used by the base operations, then use these base operations to build an upgrade, then use those to build a sync. By the time we get to a sync operation, we really shouldn't have much left to code at a low level, unlike the current code base. -Dan