On Wed, May 04, 2005 at 11:00:22AM +0200, Geert Hendrickx wrote:
> Your solution looks a lot like FreeBSD's portupgrade, or Gentoo's
> emerge.  While these may be pretty damn handy tools, they still have
> disadvantages. 

I don't know either of these tools.

> Even with smart dependency-ordering, the running system
> may be unstable/ unusable during the update. 

I explicitely accept this (as I've noted).

> And when a build fails and
> the old package is restored in place, you could suffer from binary
> incompatibilities if some dependendancies have already been upgraded.  

If a build fails, the whole 'old' dependancy tree should be reinstalled
if you really want to go back. I've assumed you carry on until the fix
is in and the package builds again.

> 
> What would be best, in my opinion, is a frontend to combine pkg_chk and
> pkg_comp.  

Please have a look at the bottom of my message. The thing in question is
not which tools do the job, but rather the algorithm they use. There's a
script which combines pkg_chk and pkg_comp (hubert's blogged it, the link
seems dead though [1]).

> Using pkg_comp, you can just nuke the to-be-updated packages
> in the chroot, and rebuild them from scratch, according to pkgchk.conf.
> Nothing gets rebuild twice, no advanced dependecy ordering required.

Except you have to build everything, not only those packages which are
out of date. If you have 20 outdated packages, 50 further which depend
on them (recursively) and 250 installed, you're building 180 packages
for nothing. Additionally I wouldn't call the ordering anything like
"advanced". ISTM quite trivial and basic actually. Or in other words,
just the "right" thing to do.

> Also, the running system just keeps running.  When a build breaks,
> nothing is damaged.  And only when each package has finished building,
> the admin starts a binary upgrade. 

As I've written above and in the original message, I'm aware of how
pkg_comp smoothes things. I dislike the idea of requiring 'external'
scripts if pkgsrc itself could do better. E.g. with buildlink, I wonder
if 'required installed package' really should be 'reqiured package visible
from the buildlink view', and thus if make update could first build everything
and then, if building everything was successful, only start deinstalling and
installing. I.e. with ok dependancies, there _might_ be no need left for either
pkg_chk in its "updating" function, nor for pkg_comp. But I don't know enough
about pkgsrc/buildlink to say anything in this area (and thus I didn't in the
original message).

> Two big advantages: not only the
> downtime is minimized to five minutes or so, but also the "risky part",
> which has to be carefully monitored by the sysadmin.  e.g., he can start
> the massive sandboxed build on friday night (unmonitored), and can do
> the actual upgrade on monday morning (after his coffee, of course).  

Again, I'm aware of pkg_comp's pros. Doesn't mean pkgsrc itself couldn't
do better.

Regards,

-Martin

[1]: http://www.feyrer.de/NetBSD/blog.html#20050117_1317