Subject: Re: Smarter make update / pkg_chk algo
To: Greg Troxel <email@example.com>
From: David Brownlee <abs@NetBSD.org>
Date: 05/25/2005 12:59:51
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
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 --