On Jul 30, 2007, at 9:06 AM, Ralf S. Engelschall wrote:

> On Mon, Jul 30, 2007, Jeff Johnson wrote:
>
>> On Jul 30, 2007, at 7:44 AM, Thomas Lotterer wrote:
>>
>>> On Sunday, 29. July 2007 at 9:28 pm, Jeff Johnson wrote:
>>>> Shall we finally eliminate the option?
>>>>
>>> Please keep. I recently succeeded with my personal BDB example case
>>> (will post details of my failures later) but one issue remains.  
>>> It seems
>>> to me all the locking stuff does not work reliably for DB_CREATE. If
>>> multiple processes try this simultaneously then damage is done. The
>>> bottom line for me is to try using BDB in a way where only one  
>>> piece of
>>> code actually initializes the database. And my constant goal of
>>> reproducibility prefers explicit action.
>>>
>>> IMHO the best solution would be to remove DB_CREATE from all
>>> db(env)->open but the single one called by "rpm --initdb".
>>>
>>> All other use cases, whether rpm or 3rd party applications,  
>>> attempting
>>> to access a database which does not yet exists should bail out.
>>> Easy to implement, document and understand. No magic. No special  
>>> cases.
>>
>> Since --initdb has no semantic that should (in my POV) differ from
>> a lazy open -- including fixating users, etc --, the --initdb can be
>> trivially
>> added as a popt alias for
>>     rpm alias --initdb -qa
>
> But why do you think that something named "init" should have the same
> semantics that something named "open"? "init" for me at least means
> _initialization_ and this IMHO should be even some sort of a  
> destructive
> initial operation for the RPM DB. Not the same as a harmless query.
>

In theory, "init" and "open" could have different semantics.

In actuality, init/open on an rpmdb should not have different  
semantics and with
lazy open's doing "init", open and init cannot differ.

> But anyway, I personally at least wish an option (independent what it
> is named) that one can use to create an initial empty database and
> (optionally) consisting of _all_ database files. Until now --initdb
> served this purpose just fine (at least with the mentioned patch to
> ensure that all files are opened and this way created).
>

Need noted. A macro to open all indices will be added, rpm -qa will
take care of the rest, and the operation will be entirely opaque and
hidden.

The real flaw is that a bit needs flipping for lazy open on
previously non-existent index, openall is the wrong fix.

>> That has the further advantage of indicating that, indeed, -- 
>> initdb is
>> harmless when run repeatedly.
>
> I don't think this is an advantage. Why should anybody wish to
> initialize a database multiple times?
>

Why would anyone not believe me when I say "harmless"? See thread
last fall on rpm-list, wherein I'm accused of not specifying --initdb  
clearly
enough in man page, and depriving users of the joys of --verifydb by  
keeping the option
hidden. The real flaw was mmap(2) in the linux kernel ...

BTW, expect --verifydb to go in the trash bucket too, in favor of  
external db_verify
or db_tool.

73 de Jeff