Subject: Re: Smarter make update / pkg_chk algo
To: Gavan Fantom <gavan@coolfactor.org>
From: Rhialto <rhialto@azenomei.knuffel.net>
List: tech-pkg
Date: 05/07/2005 14:38:33
On Sat 07 May 2005 at 11:45:24 +0200, Gavan Fantom wrote:
> The script currently does the following:
> 
> * Invokes pkg_chk to get an initial list of stuff that is out of date
> * Walks up the installed dependency tree to add to the list all packages 
> which depend on anything already in the list
> * Removes from the list any packages which are dependencies
> 
> This leaves us with a list of packages which are at the top of the tree, 
> which need building. In your example, ORBit and tiff would be expanded 
> to everything that depends on ORBit and tiff, and would then be reduced 
> to top-level packages, such as meta-pkgs/kde3.

That sounds like a good strategry. Too bad that it is so slow. I gave up
on it after letting it run for 15 minutes or so.

So I tried another strategy, that should hopefully get about the same
result. I did, in the chroot, a pkg_chk -r to remove all outdated
packages and those that depend on them. Then I did a pkg_chk -a to add
them back.

pkg_chk installs binary packages itself, if it determines one is
available.

Ordering for pkg_chk seems to depend strongly on the order of
pkgchk.conf though. If it decides to install a binary package, all its
dependencies should already be installed or also available as binary
packages. The version that is initially created by pkg_chk -g seems to
be correctly ordered (maybe by coincidence??), but updates need to be
done carefully.

I noted one problem with binary packages that depend on Perl. I had some
perl modules for Perl 5.8.5. Now that I have Perl 5.8.6, these should be
recompiled since the installation directory is different. However this
did not happen - the versions were still the same. And it's not really a
solution to bump the version (or the version of Perl that's required)
because you really don't want to require the newest Perl in all cases.

> In general, you can't do this. You need your binary packages not only to 
> be internally consistent, but also consistent with respect to the other 
> packages on your system.

I think that's the case. Inside my chroot I started out with the same
versions of the same packages as on my real system, and I have been
updating them (with various strategies so far, though they should all
haved preserved consistency).

-Olaf.
-- 
___ Olaf 'Rhialto' Seibert                            --  rhialto/at/falu.nl
\X/ Hi! I'm a signature virus! Copy me to your .signature to help me spread!