[pacman-dev] libalpm issues (was: alpm_removedeps bug+fix && alpm_depcmp-discussion)

[Dan McGee]

On 6/18/07, Xavier <shiningxc at gmail.com> wrote:
> 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 :)

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