Subject: Re: proof of concept pkg upgrading tool
To: fab <>
From: Peter Schuller <>
List: tech-pkg
Date: 09/21/2005 22:42:14
> I already recurse things, when new dependencies are added, they are
> considered as a new pkg to upgrade so I find pkgs depending on it.
> And yes, parsing a text file is _much much_ faster than calling make,
> but if I can solve many problems using make, I'm open to suggestion.
> I think the good way is to do "up" method, when you want to upgrade
> gtk+, the dependencies that matter are sylpheed, not xorg...
> In this little prog, one package is one object, and adding some kind of
> cache to properties (for them to be computed once) is _very_ easy, just
> it adds code, and now the only researched behaviour is correctness, not
> speed.
> One solution could be to call show-var VARNAME=DEPENDS on *all*
> packages who are in /var/db/pkg and then do the job with reverse
> information built... do you think it will be better ?

FWIW, in pkgmanager I use 'make print-summary-data' (instead of
multiple 'make show-var':s) on each directory in the pkgsrc tree. This
has worked fine so far.

The problem is that it's *slow*. As a result pkgmanager caches this
information. But this brings up the next problem - how to accurately
and quickly determine when a package has been updated. Currently the
modification time of the diretcory is used, because that works
fairly well given how CVS does updates. But it is not fool proof,
and I have received at least one report of problems because of it.

My next plan is to look at the modification time and/or md5sum of
*all* files in the package directory (ignoring work/). It should still
be faster than 'make print-summary-data' (I have not measured the
relative speed of 'make show-var').

Anyways... that is my experience. Perhaps you can do something similar.

/ Peter Schuller, InfiDyne Technologies HB

PGP userID: 0xE9758B7D or 'Peter Schuller <>'
Key retrieval: Send an E-Mail to
E-Mail: Web: