Subject: Re: Smarter make update / pkg_chk algo
To: David Brownlee <abs@NetBSD.org>
From: Greg Troxel <gdt@ir.bbn.com>
List: tech-pkg
Date: 05/25/2005 07:39:22
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'.

  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.

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

-- 
        Greg Troxel <gdt@ir.bbn.com>