today, i played around getting rpm5 compiled with:

  --with-db=no --with-sqlite=<installpath>

the reason is:

  - get a smaller footprint (embedded system)
  - berkeley db 4.6.21 is not support on qnx (at least no w/o patches)

it compiles with only a few changes (see attached patches)
most of them seems to be uncritical or QNX specific:

   patch-aa (configure.ac): don't stop, if --with-db=no is specified
   patch-ab (configure): resulting configure.ac changed in configure
   patch-ac (system.h): u_int32_is not defined for qnx neutrino
   patch-ad (macros.in): changing default from berkeley db to sqlite

patch-aa/patch-ab: i assume they are uncritical
patch-ac: qnx neutrino specific (is it the right place?)

patch-ad: critical, but is it really needed?


i hope, that this way will bring us to a clean solution for qnx in 5.0.1

note, that it's not yet tested (it compiles and rpm show the helpscreen). rest will follow...

-piet

btw: the rest of the file is the stuff needed for the netbsd pksrc system

-------- Original-Nachricht --------
> Datum: Sun, 27 Jan 2008 15:14:18 -0500
> Von: Jeff Johnson <n3npq@mac.com>
> An: rpm-devel@rpm5.org
> Betreff: Re: Releasing rpm-5.0.1

> 
> On Jan 27, 2008, at 3:03 PM, Peter Kalbus wrote:
> 
> > you're right, the --with-db=no seems to produce a lot of errors.
> >
> > but, how can i prevent people from building db based systems?
> >
> 
> Dunno. Users like choice ...
> 
> > if they can, they will do and if it fails, nobody will ask, but  
> > will say, that rpm5 has a bug on qnx.
> > i don't like those lines. so, i'd like to get a solution, which
> >
> >   - either is worlig with db support
> 
> db-4.7 (or reverting to last known working on QNX) are the easiest
> pathways. DB_PRIVATE is viable, SuSE uses DB_PRIVATE
> in "production" (but there is definite feature reversion with
> using a global shared/exclusive lock and I'm not interested
> in going backwards in rpm-5.0).
> 
> >   - or preventing from using it, as much as possible
> >
> 
> Preventing is not as good as supplying the reasons so
> that users can make informed choices.
> 
> > will the below mentioned change set any default to sqlite3?
> 
> Changing the 3 to 4 in the 2 macros will use sqlite3.
> 
> > can anyone switch back to berkeley db from the command line?
> 
> There are db conversion issues, so its not like one can just flip
> between bdb <-> sqlite3. But yes, macros can be set from the command  
> line.
> 
> > what about an existing berkeley db database and the rpm5 version?
> >
> 
> If you have a rpmdb in Berkeley DB format, you kinda need a
> Berkely DB implementation to read. That's true for Oracle, postgres,
> sqlite3, etc etc as well.
> 
> 73 de Jeff
> ______________________________________________________________________
> RPM Package Manager                                    http://rpm5.org
> Developer Communication List                        rpm-devel@rpm5.org