Subject: pkg_delete -r [was: Re: CVS commit: src]
To: Christian E. Hopps <firstname.lastname@example.org>
From: Hubert Feyrer <email@example.com>
Date: 02/26/1999 15:08:48
On Fri, 26 Feb 1999, Christian E. Hopps wrote:
> Module Name: src
> Committed By: chopps
> Date: Fri Feb 26 10:49:30 UTC 1999
> Modified Files:
> src/usr.sbin/pkg_install/delete: delete.h main.c perform.c pkg_delete.1
> Log Message:
> add -r flag to delete all packages that require the user specified one
Um, thanks for adding this. Having worked on the very same problem a few
days ago, I'll take the freedom to make some comments here:
- 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.
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".
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 .-)
- in the implementation of strequal(), wouldn't it be faster to just
do the strcmp(), instead of scanning the string twice before with
- Last but not least, Christian: please check with firstname.lastname@example.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!
Hubert Feyrer <email@example.com>