On Wed, 25 May 2005, Greg Troxel wrote:

> That sounds like a nice change, and enough to obsolete make update.  I
> have two perhaps not quite on-target suggestions:
>
>  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?

>  I'm doing bulk builds and wanting to update other machines.  What
>  you've done should be very helpful, but I'd like to be a bit more
>  intentional about what packages are installed.  I'd like to do
>  'pkg_chk -g' and install from that, but would like to be able to
>  hand-edit the file, and then generate a diff.  So two features that
>  would be useful would be
>
>    an option like '-g' that takes an existing pkgchk file, and only
>    outputs installed packages that aren't covered by the existing
>    file.  This lets me find out what's new, and lets me have an
>    organziation/project standard package list, and then have a local
>    additions list.

  	This could be a simple as (effectively) running -g and comm -3 on
  	the result and original file, unless you want some magic with
  	'top-level' vs dependencies, then it gets more fun.

>    a way to output only top-level packages.  I want this because the
>    maze of little libraries changes (and I don't really care), and
>    don't want this churn to be visible in the control file.

  	This would be the fun :) Would a straight variation of
  	-g which only lists the top level packages be fine?

> This last point is related to a thought I've had for a while - marking
> in /var/db/pkg someone whether a package is first-class in that
> someone asked for it specifically (make package, pkg_add) or whether
> it got built as a dependency.  The bulk build machine needs to merge
> the standard list and the local lists of all target machines.

  	That would be a nice feature.
-- 
  		David/absolute       -- www.NetBSD.org: No hype required --