On Wed, 25 May 2005, Greg Troxel wrote:

>  >  Instead of recursive removal of mismatched packages, make a list of
>  >  what needs removing, and what will be added, tsort it, and 'pkg_add
>  >  -u' or 'make replace' down the list.  This should result in the same
>  >  end state, but have fewer missing packages during the process.  But,
>  >  packages may fail in more interesting ways, rather than 'command not
>  >  found'.
>
> 	  How would that hand the case of pkgA and pkgB both needing
> 	  update and both being dependencies of firefox?
>
> pkgA pkgB and firefox would all be in the 'need (possibly recursive)
> removal', and hence in the tsort, and then one would
>
>  pkg_add -u pkgA-new
>  pkg_add -u pkgB-new
>  pkg_add -u firefox-new
>
> so if A or B changed shlib versions or other interfaces, firefox would
> be broken for a bit, but if not the window would be small.

 	This implies in-place updates without first removing packages
 	that depend on each package? That is not something pkg_chk
 	has ever done, so I'd need to think more about it.

> 	 This would be the fun :) Would a straight variation of
> 	 -g which only lists the top level packages be fine?
>
> I think I'd still want more :-), but that would be a huge help.
> Using sort/comm/etc. could get me the 'packages not in other list'
> part.  I expect to do some hand editing, and my main pkg_chk files
> have comments about why packages are needed.  So ending up with a list
> of packages that are top-level in the current system but that aren't
> listed in another file probably fully implements what I would like.

 	I'll see how many more options flags I feel like burning :)

> I really appreciate that you made pkg_chk work without pkgsrc present
> - that makes it very useful (vs. not applicable) in my testbed
> environment, where I don't have any sources on most of 21 notebooks,
> and mostly use a single build machine.

 	That is quite similar to my usage here - except that to update
 	a machine I run 'pkg_chk -l' on the build box to determine the
 	list of packages, push them to the destination host and then
 	install them there (this is assuming the build host always
 	builds everything)

-- 
 		David/absolute       -- www.NetBSD.org: No hype required --