Subject: pkg_delete -r [was: Re: CVS commit: src]
To: Christian E. Hopps <>
From: Hubert Feyrer <>
List: tech-pkg
Date: 02/26/1999 15:08:48
Hi Christian,

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
   (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 

Hubert Feyrer <>