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>