Subject: Re: update pkgsrc package
To: David Brownlee <>
From: Jeremy C. Reed <>
List: tech-pkg
Date: 05/17/2001 07:12:04
On Wed, 16 May 2001, David Brownlee wrote:

> 	Ensure you do not have any previous built packages around in the
> 	pkgsrc source tree, then run 'make ; make update' in the appropriate
> 	directories for each package.
> 	'make update' rebuilds all the dependencies, this has a number of
> 	issues:
> 	    a) It can take a very long time...
> 	    b) While its updating a package any package which depends on
> 	       that package will have been removed from the system. Be
> 	       very wary about updating a library on which your window
> 	       manager or similar depends.
> 	    c) If the update breaks, it can leave you without the
> 	       aforementioned packages.
> 	    d) If you pick a suboptimal order you can end up rebuilding
> 	       much of your system several times. Pick the package on
> 	       which most other packages depend first.

Is there any tool to help figure out the common denominator?

For example, a tool where it reads from standard input the list of
packages; then it builds a list of all the dependents (+REQUIRED_BY) of
these packages; and outputs a list of all the dependents in order of how
many times it is a dependent (or lists the common parents).

> 	    e) Sometimes there is no optimal order - eg, half your system
> 	       depends on pkg 'a' and pkg 'b', but they do not depend on
> 	       each other. So you end up rebuilding everything twice. Of

In this situation, would it be better to just recursively pkg_delete all
of the packages (you want to update) and 'b' and then -- instead of using
"make update" -- just "make install" each package? Then everything will
only be deleted once and installed once.

Am I understanding this correctly?

> 	       course if they both depend on pkg 'c' which is up to date
> 	       you can run 'make update' on pkg 'c' which would be quicker..

That is a good idea. So it would be good to have a tool that quickly told
you which packages the others depend on. For example, on one of my
systems, "lintpkgsrc -i" results in 67 version mismatches; it would be
nice if I could easily figure out sommon common denominators for these.

   Jeremy C. Reed