Re: Building RPM 4.00

[Jeff Johnson <jbj JBJ ORG>]

On Wed, Nov 01, 2000 at 11:53:15AM +0100, Rene de Zwart wrote:
> Hi,
> 
> I have managed to build rpm 4.0 an interesting 8 hour tour.
> I share my experience and observations her in the hope that
> 1) you can enlighten me what I have done wrong

You're braver than me, as I have yet to look at compiling rpm-4.0
(and Berkeley db and bzip2 and ...) on Red Hat 5.2 ...

> 2) if I failed to comply to 1 maybe it is helpfull to make
>    installing rpm 4.0.x an effort less installation

... which is why the installation requires effort.

> 
> Conclusion (for those who don't want the read the whole email).
> The upgrade to 4.0 wasn't simple for me.
> 
> 1) Catch 22 situation in order to install rpm4.0 you need rpm4.0
>    Maybe it is possible to make a basic rpm4.0.rpm version
>    created with rpm version 3.0

The "easy" fix for this would have been to upgrade to rpm-3.0.5
before you started (although rpm-4.0 build would still have failed
on Red Hat 5.2 for many reasons).

> 2) Big problem installing from tar (with hindsight) was the
>    assumptions made by installing db packages.
> 	a) it need to be shared (gives you different versions of the
> 	   libs) Therefor in INSTALL the --enable-shared should be
> 	   include
> 	b) the different include file versions are assumed to
> 	   be in db$MAJOR_VERSION/db.h which isn't installed default so
> 	   that's something needs to be done by hand.

The "easy" fix here would have been to look at how db3 (and db1) is
packaged.

Conventions like paths and file names are often established in
spec files from packages. This is particularly true for Berkeley db packages,
as changes are necessary to permit all of db1, db2, and db3 to coexist
on the same machine.

> 3) The (default) locations for de package database seems to be
>    different. 

Not true. The db1 names (i.e. "foo.rpm") have been deliberately changed
for db3 support (i.e. "Foo") in order to prevent accidental deletion
of files during --rebuilddb. The location of the rpm database is the
same as always, /var/lib/rpm.
> 
> 
> My system was an original redhat 5.2 system which has been
> upgraded by rpm's and hand installs. the kernel I'm running is
> 2.2.17. This may also be a cause for confusion in this process.
> 
> First its a bit of a catch 22 situation if you download an
> binairy version you get:
> only packages with major numbers <= 3 are supported by this
> version of RPM
> error: /tmp/rpm-4.0-4.i386.rpm cannot be installed
> 

rpm-3.0.5 fixes this.

> 
> So maybe if an rpm is needed one created by 3.x version is
> necessay.
> 
> I than proceded  with rpm-4.0.tar.gz (from www.rpm.org).
> 
> The same problem as installing the binairy rpm-4.0.x is probably
> true for the db-3.1.14*.rpm which is there to. I haven't downloaded
> it but instead went to sleepycat.com and downloaded
> 
> db-3.1.17 (ofcourse I could see that 3.1.14 was used in rpm-4.0
> so maybe this lead to problems anyway)
> 
> The only targets db-3.1.17 has are:
> 	PROGS=   db_archive db_checkpoint db_deadlock \
> 		db_dump db_load db_printlog db_recover db_stat db_upgrade
> 		db_verify
> 
> 	libdb=      libdb.a	
> 
> The configure scripts tries to check in libdb, libdb-3.1, libdb-3.0
> for db_create and dbopen
> 

The rpm 4.0 configure tests are appropriate for linux, possibly only the Red
Hat 7.0 persuasion of linux.

> db_create
> 	Offcourse if will succeed for libdb with db_create. I failed
> 	to understand how libdb-3.1 and libdb-3.0 would get there and
> 	wonderd if they were necessary (I know in the development
> 	environment it was). Oooh, I just found out those are the shared
> 	libraries. Then INSTALL should contain the line 
> 	../dist/configure -enable_shared (got me wrong there)
> 

A full blown autoconf test to automagically use the correct available
Berkeley db libraries in rpm would have to:
	1) Search all possible paths for libdb*.
	2) Search all possible variant names, not just the hopelessly
	naive libdb.a.
	3) Determine what other libraries, like -lpthread, are necessary
	for symbol checks.
	4) Filter out multiple occurences of libdb*, as (at least on non-linux
	operationg systems), there are often downrev db libraries delivered
	with the OS that have been corrected by installing other (downrev)
	versions of libdb in other places from the mess above.
	5) Filter out multiple occurences of the db-1.85 compatibility
	interface from the mess above. This may also require the location
	of db_185.h to be ascertained, dunno.
	6) Finally, map everything above so that it is user selectable.

I thought about implementing the test above, gave up because life's far too
short ...

> dbopen
> 	dbopen seems to be only there if you #include <db_185.h>
> 	which does:
> 	#define dbopen  __db185_open
> 	DB *__db185_open __P((const char *, int, int, DBTYPE, const
> 	void *));
> 	Linking fails which means that db1.c will not be included.
> 	And db1.c refers to #include <db1/db.h> 
> 	And db2.c refers to #include <db2/db.h> 
> 	And db3.c refers to #include <db3/db.h> 
> 	which isn't created by installing db unless you do and make
> 	a link like ln -s /usr/include/db3/db.h /usr/include/db.h
> 	fall back to the old db libraries but the headers are out of
> 	sync if you do normal installion. And the synchronosation
> 	between the headerfile and library might be wrong there to.

Or if you have the db-1.85 package installed (which you are going to
need since the on-disk formats are incompatible between db1 and db{2,3},
and the db_185.h compatibility API won't fix this).

FWIW, here's the configure line in the db3 package:

CFLAGS="$RPM_OPT_FLAGS" ../dist/configure --prefix=%{_prefix} --enable-debug --enable-compat185 --enable-diagnostic --enable-dump185 --enable-shared --enable-static --enable-rpc --enable-tcl --enable-cxx --enable-test

There are other changes in the db3 package to achieve static/shared library 
compilation, altered paths, and renamed files as well.

> 
> Then in the end you have got the problem with db1basename()
> but that has already been answered on deja by Jeff Johnson 
> his suggestion is simple to move db1basename() to a file which
> get included.
> 

At the moment, rpm-4.0 requires both db1 and db3 to be installed, so that ...

> The only problem I'm faced with now is that I'm not able to
> convert my old rpm database to the new one because 
> a) they look in different places (easily solvable)
> b) they look for differen things package.rpm versus Package.rpm
> Any suggestions for those?
> 

... old databases can be converted.

Hope this helps. Truly, think carefully before trying rpm-4.0 on Red Hat
5.x, as most of what you need/want
	a) ability to read version 4 packaging (packages produced by rpm-4.0)
	b) same build configuration as rpm-4.0
is in rpm-3.0.5 and later, and the rest of the changes needed to deal with
legacy incompatibilities are quite painful.

73 de Jeff

-- 
Jeff Johnson	ARS N3NPQ
jbj@jbj.org	(jbj@redhat.com)
Chapel Hill, NC