Subject: Re: update pkgsrc package
To: David Brownlee <abs@netbsd.org>
From: Jeremy C. Reed <reed@reedmedia.net>
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
http://www.reedmedia.net/