> Um, thanks for adding this. 

Your welcome.

>  - The error message you give if a package can't be deleted ("had problem
>    removing ...") should rather indicate that it's likely that some other
>    package still needs this package. Also, you should then stop deleting
>    any pkgs further down the dependency tree. 

But unless there is a problem with my code this isn't true.  It
will be some other problem.  I do stop deleting unless the force
flag is set.

>    I don't fully understand the code in recurse_require_find() to say how
>    the list of packages to delete is build, but maybe you can check this. 
>    Having a topologically sorted list would ensure the least trouble here. 
> 
>  - A major problem (yet to be solved by someone) is that you need to do
>    a topologic sort for the packages before you can start deleting.
>    E.g. imagine a package "a" depending on "x", and "x" depending on "c".
>    a->x->b
> 
>    As it stands right now (and i'll probably change that this weekend if
>    noone/nothing else gets in my way), any binary package "a" will
>    depend on both "b" and "x" (in that order!!!), and if you start
>    deleting now, you can't delete "b" as "x" is still installed.
> 
>    The best solution would be some topologic sort - if you got a solution
>    for this, let me know. :) (The queue you implement should be a good
>    start for this, we'd just move things around to do the sort .-)

If you look at the code its doing this already.  Its decending to
the leaves of the tree before adding things to the rddelq.
Things are added to the tail of the rddelq.  Thus the head of the
queue is some package that is required by no-one. rdfindq
represents the branch on the tree and is used to detect circular
dependencies.

>  - in the implementation of strequal(), wouldn't it be faster to just
>    do the strcmp(), instead of scanning the string twice before with
>    strlen()?

Yes, thanks I changed it.

>  - Last but not least, Christian: please check with tech-pkg@netbsd.org
>    (most notably agc and me, and I've also heared that tv is doing some 
>    work on these tools) if/before you make any future changes to any
>    part of the packages system. We try to get a grip on the code, and
>    that's hard to get if there's no communication. Thanks in advance!

I asked Al before committing it.  Sure I could have posted
somewhere to find out if anyone else was working on it, but to be
honest I figured since it wasn't commited the answer to that
question was that no-one was.  It was a one night program.  Thats
not to say people weren't thinking about writing it, but I've
been asking for this feature for months, and I got tired of it
and decided to help the project out.

Thanks,
Chris.