On Wed, 03 Aug 2005 20:51:39 +0200 (CEST)
Havard Eidnes <he@uninett.no> wrote:

> > Wouldn't pkg_chk do the work?
> 
> Just to answer this, I tried it once, and was disappointed by the
> result -- as I recall it ended up compiling several packages more
> than once.

Are you perhaps referring to the problem described at the end of the
pkg_chk manual page?

I usually use pkg_chk like this when I want to update my system:

pkg_chk -g    To generate an uptodate pkgchk.conf
pkg_chk -r    Remove all packages not up to date and also packages
              depending on them
pkg_chk -ask  Add missing packages by building from source. Keep
              going even though some package fails to build. I can
              fix that later.

(a bit unsure about the -ask flags. Perhaps an u should be there
instead of the a (-usk). It has been a while since I last used pkg_chk,
actually.)

I think pkg_chk is good to use when leaving a system building packages
over the weekend.

On an SMP system it is possible to cut build times in half (roughly) by
creating a "meta package" from the pkgchk.conf file and running with
the parallel-patch I posted about a couple of months ago. On a fairly
large amount of packages it will crunch for 15 minutes or so to create
the generated makefile. After that the builds will start and the -j
flag will do its magic and in the common case both CPUs will be busy.
Often big packages like qt, kdebase and kdelibs are built at the same
time as some gtk dependancy chain of packages. Or firefox.

It might be good to run pkg_chk -f to make sure all distfiles are
available since I have not yet found a good way for the 'parallel'
target to properly lock the distfile directory when two different
packages are using the same distfile..


Best regards
	Lars Nordlund