Subject: Re: Package update disaster
To: Florian Stoehr <netbsd@wolfnode.de>
From: Steven M. Bellovin <smb@research.att.com>
List: netbsd-users
Date: 10/07/2004 04:10:49
In message <Pine.NEB.4.61.0410070956010.14006@flo.login-solutions.local>, Flori
an Stoehr writes:
>On Wed, 6 Oct 2004, Steven M. Bellovin wrote:
>
>> In message <Pine.NEB.4.61.0410070022150.251@irina.net.flo>, Florian Stoehr w
>rit
>> es:
>>
>>>
>>> Is there a perhaps simpler way to tell pkgsrc:
>>> "bring-EVERYTHING-up-to-date-and-don't-ask-for-further-input" ?
>>>
>>> "make update world"-like?
>>>
>>
>> There is, but it's a bit complex.  Here's a posting from Wolfgang S.
>> Rupprecht on 31 May 2004:
>>
>>
>> ---
>> Date: Mon, 31 May 2004 21:01:45 -0700
>> To: port-i386@NetBSD.org
>> From: "Wolfgang S. Rupprecht" <wolfgang+gnus20040531T202330@dailyplanet.dont
>spam
>> .wsrcc.com>
>> Subject: Re: pkgsrc and already installed binary pkgs
>>
>>
>>> No, it's not great.  But there aren't great solutions here, unless
>>> there's a thorough archive of many different versions of many packages.
>>> And it's even worse than I've just outlined, since you'll often find
>>> that something doesn't rebuild properly.
>>
>> I've been looking at how some of the other BSD's handle this, and
>> pkgsrc (especially when augmented with pkgdepgraph and pkg_chk) is way
>> above the competition.
>>
>> I found that updating the pkgsrc tree to -current and then using
>> "lintpkgsrc -i" to find the out of date pkgs and updating with
>> pkgdepgraph is the least painful way to go.  Pain is relative though
>> and if something fundamental like png changes, expect 10-20 hours of
>> an unusable system with only the core non-pkgs utilities.
>>
>>    set -e
>>    cd /usr/pkgsrc
>>    cvs -dAP
>>    lintpkgsrc -omr
>>    lintpkgsrc -i > pkgdepgraph.in
>>    pkgdepgraph -D pkgdepgraph.in > delete_order
>>    pkgdepgraph -R pkgdepgraph.in > rebuild.sh
>>    pkgdepgraph -F pkgdepgraph.in > fetch.sh
>>    sh fetch.sh && mv fetch.sh fetch.sh~
>>    pkg_delete `cat delete_order` && mv delete_order delete_order~
>>    sh rebuild.sh
>>    /bin/rm -f pkgdepgraph.in delete_order~ rebuild.sh fetch.sh~
>>
>> Now on bad days, I may need to find what didn't rebuild, comment out
>> the broken build on rebuild.sh and rerun that by hand.  Still it beats
>> rebuilding it all by hand.
>>
>>
>> 		--Steve Bellovin, http://www.research.att.com/~smb
>
>Uh!
>
>On a this-is-simple scale ranging from "1" to "10", this is a "12" :-(

Well, I did describe it as "a bit complex"...
>
>Hm ... maybe we should think about a mechanism for this, maybe also for a 
>binary package updater? Just a though.
>

I agree.  What I like best about this scheme is that it's reasonably robust,
and lets you recover from compilation failures -- you have a record of 
the state before wiping out everything.

I agree that we should package it up.  It does need some improvement; 
it doesn't deal properly with packages that have been renamed, and 
hence generate errors from lintpkgsrc.
>


		--Steve Bellovin, http://www.research.att.com/~smb