Subject: Re: Use of `pkg_chk`
To: Richard Grace <rgrace@aapt.com.au>
From: Steven M. Bellovin <smb@research.att.com>
List: netbsd-users
Date: 06/06/2002 07:42:04
In message <scffa318.050@aapt-gwia2.aapt.com.au>, "Richard Grace" writes:
>Howdy folks.
>
>I've recently discovered the reason for the following comment in the 
>pkg_chk(1) man page, when I tested pkg_chk on the pth-1.4.1 package.
>
>BUGS
>                                              ...  However, if a depends on b
>     and c, and all three are marked for update, pkg_chk will update b and c
>     in two separate passes, resulting in unnecessary rebuilding of a (and po-
>     tentially other packages).
>
>It compiled all sorts of things over and over until after about four
>days, when I noticed it was still running, I killed it.
>
>Now I'm wondering how many packages I will have to reinstall by hand,
>as I've discovered that most of gnome is missing, and though xmms will
>load, it won't play any tunes :-(
>
>As far as I can tell there are no logs.  I guess it's just a case of
>removing, and reinstalling all of the major apps, and seeing what
>happens to the dependancies?
>
>Any suggestions for a better way to do this in the future will be
>greatly appreciated :-)
>

Something I tried -- but failed at -- was to look at the package 
database and -- given a starting point -- to build a dependency tree so 
that I'd know what order in which to buind things.  But I couldn't 
figure out where the dependency information for compilation was stored, 
and I didn't have time to pursue it.

That would be an add-on tool, and it would be a good thing in any 
event.  What I'd like as a change to the package system is to have 
'make update' do the compilation first and then the remove/install, 
rather than remove, compile, install.  I see some of the reasons why my 
scheme is harder -- but it strikes me as sufficiently obviously the 
right way to do things that I'm not sure why the effort wasn't expended.

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com ("Firewalls" book)