On Jan 26, 2010, at 6:27 AM, Bernhard Rosenkränzer wrote:

> On Tue, 26 Jan 2010 10:26:23 +0100, Bernhard Rosenkränzer
> <bero@arklinux.org> wrote:
>> On Mon, 25 Jan 2010 23:42:37 -0500, Jeff Johnson <n3npq@mac.com> wrote:
>>> On Jan 25, 2010, at 3:22 PM, Bernhard Rosenkränzer wrote:
>>>> trying to install a new system into a chroot jail currently fails:
>>>> # rpm -r /mnt/dest -ivh /RPMS/*.rpm
>>>> rpm: rpmdb.c:254:dbiOpen: Assertion `__dbapi == 3 || __dbapi == 4'
>>>> failed.
>> 
>> /usr/lib/rpm/macros and /usr/lib/rpm/macros.d are both there,
>> /usr/lib/rpm/macros has %_dbapi 3 set, and rpm (same binary) looks into
>> that file on an installed system.
> 
> Figured it out:
> 
> Recently,
> 
> %{load:%{_usrlibrpm}/macros.d/selinux}
> 
> was added to /usr/lib/rpm/macros
> 

Yep.

(aside)
There's several parallel implementations on HEAD headed for rpm-5.3.

The assert failure you see is misleading and painful atm. The only redeemonh
feature is that rpm comes FULLSTOP when it becomes misaligned with
necessary configuration.

The "fix" is more complicated than juts compiling in
	%_dbapi 3
as default (this is what used to be implemented) if/when rpm failed to read
its macro configuration.

What's needed instead is to remove all the database configuration except
	1) which tags should have tables generated.
	2) whether btree/hash should be used for the tables.
All other rpmdb configuration should be done using DB_CONFIG imho.

The %{load:...} constructs for large optional subsystems like
SELinux or "building with perl" like configuration should
be done through other means.

All of which ultimately means that rpm-5.3 will never succeed
in attempting to simplify macro configuration becuause
of previous expectations. But there's no harm in trying
to so simplify
	Have it your own way!
to be something other than
	Make everything configurable and preconfigure everything
	multiple ways.

> That file exists in the installed system, but not in the minimal bootstrap
> system we're installing from.
> Looks like rpm aborts parsing a macros file if it contains a load
> statement referring to a nonexistant file, without giving an error message
> about it.
> 
> It's a user error for leaving that load statement in, but an error message
> (or better yet, a warning message plus continued parsing of the file) would
> be nice...
> 

Yep. SUre the error message sux toads and needs better. But the real fix
is deeper than just adding a better error message.

hth

73 de Jeff