pkgdb format

[Mark Ovens]

Colin Percival wrote:
> Mark Ovens wrote:
>> After reading this thread, I killed the upgrade, deleted INDEX-6,
>> INDEX-6.db, and pkgdb.db; rebuilt pkgdb.db using `pkgdb -u' and re-ran
>> `portupgrade -af'
>> 
>> It started off OK (using dbm_hash) but after a couple of hours it had
>> started continually rebuilding pkgdb.db.
>> 
>> Anyone else got any ideas?
> 
> I had exactly the same problem during portupgrading after a 5.4->6.0
> base system upgrade until I did a `portupgrade -fR portupgrade`, at
> which point it stopped (and has been fine ever since).  I have no idea
> what the problem is or why this would fix it, but you might like to
> try this and see if it helps.
> 

Thanks! That seems to have fixed it for me too - it's now using 
bdb1_btree consistently :-)

As to why, I'm not sure, but here's what upgrading portupgrade the way 
you suggested affects:

/home/mark{101}# portupgrade -fRn portupgrade

[snip]

--->  Listing the results (+:done / -:ignored / *:skipped / !:failed)
         + databases/db4 (db4-4.0.14_1,1)
         + lang/perl5.8 (perl-5.8.7_2)
         + lang/ruby18 (ruby-1.8.2_5,1)
         + databases/ruby-bdb (ruby18-bdb4-0.5.7)
         + sysutils/portupgrade (portupgrade-20051204)
--->  Packages processed: 5 done, 0 ignored, 0 skipped and 0 failed

I don't know if any of those were actually upgraded or just reinstalled 
but databases/ruby-bdb looks like a candidate for being the culprit 
since portupgrade uses ruby so, if ruby itself and one or more of it's 
dependencies are out of sync it could explain it; i.e. if part of ruby 
got upgraded but not another by `portupgrade -af' - although if that is 
the case it is puzzling that when I aborted the first run, deleted the 
INDEX and pkgdb files that it ran OK for a while - the ports that had 
already been upgraded hadn't been downgraded <shrug>

Maybe portupgrade needs to be changed to upgrade itself 
upward-recursively first whenever the -a option is used?

Thanks again for your help.

Regards,

Mark