Subject: Re: proof of concept pkg upgrading tool
To: fab <firstname.lastname@example.org>
From: Peter Schuller <email@example.com>
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
> 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 <firstname.lastname@example.org>'
Key retrieval: Send an E-Mail to email@example.com
E-Mail: firstname.lastname@example.org Web: http://www.scode.org