RPM Community Forums

Mailing List Message of <rpm-devel>

Re: Eliminating --rebuilddb by doing lazy secondary index re-creation

From: Jeff Johnson <n3npq@mac.com>
Date: Mon 14 Dec 2009 - 04:04:36 CET
Message-id: <C231A253-7234-49B5-B8A9-39915C9F3AAB@mac.com>

On Dec 11, 2009, at 11:47 AM, Jeff Johnson wrote:

>
> On Dec 8, 2009, at 11:10 PM, Jeff Johnson wrote:
>
>>
>> On Dec 8, 2009, at 4:26 PM, Jeff Johnson wrote:
>>
>>>
>>> I'll leave the existing --rebuilddb as "opt-in" with a compile  
>>> time toggle
>>> until, say, Friday 12/11/2009 for comments before
>>> hauling out the trash from rpmdb/rpmdb.c.
>>>
>>
>
> OK, inplace --rebuilddb (and major trash hauling out of rpmdb) this  
> weekend.
>

Well --rebuilddb is now rewritten, and rpmdbRebuild() is now called  
rpmtsRebuildDB().

I'm still muddling about whether I should eliminate --rebuilddb entirely
and replace with this script:

------------------
#!/bin/sh

rpm=/usr/bin/rpm

dbpath="`$rpm -E '%{_dbpath}'`"
tags="`$rpm -E '%{_dbi_tags}' | tr ':' ' '`"
for tag in $tags; do
    [ ".$tag" = ".Packages" ] && continue
    [ ".$tag" = ".Seqno" ] && continue
    rm -f $dbpath/$tag
done
------------------

That entire script could be easily buried into a popt alias for -- 
rebuilddb.

The only other operation that --rebuilddb and rpmtsRebuildDB()
does is resetting the Seqno persistent package instance counter
to the maximum primary key.

But Seqno (like Packages) is "persistent": if you lose either Packages/ 
Seqno,
well, then you need to rely on Berkeley DB ACID logs to recreate with  
DB_RECOVER
(or db_recover), or otherwise back-up files in /var/lib/rpm.

I'll likely wait a week or three before eliminating --rebuilddb entirely
largely because I don't wish to explain why --rebuilddb is almost  
entirely
the wrong thing to do ... always has been.

73 de Jeff
Received on Mon Dec 14 04:05:09 2009
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.