Re: db3 and beecrypt in RPM source tree

[Jeff Johnson <jbj redhat com>]

On Mon, Jul 01, 2002 at 06:14:40AM -0700, greg_mu@yahoo.com wrote:
> Hi Jeff,
> 
> Thanks for the insights. I probably came up with the
> bad example in my
> original post.  I think that I can fix configure
> scripts and it's not a
> problem.  My concern is related to what I see as
> bundling multiple
> products (RPM, db3, beecrypt, etc) into a single
> deployment unit.
> 
> I see two scenarios here: initial RPM build and the
> RPM build under the
> RPM tool itself (more typical scenario).
> 
> In the first case, if you don't want to track
> compatibility with the
> older versions, it's OK to say in the INSTALL notes
> that the build requires
> db3 package equal to some specific tarball version. 
> This is quite typical
> and the users won't have any issues with that.
> 
> In the second scenario, I don't see why you can't just
> use the RPM dependency
> checks and let the other RPM packages (db3, beecrypt,
> etc.) have their own lifecycle.
> After all this is what RPM was made for 8-). Also
> please cosider that you may sooner
> or later cause a collision with the packages RPM uses
> internally when those packages
> will be installed on the system independently.  
> 
> I still do not see any benefits in bundling the
> tarballs together. After all,
> If you are not introducing some private changes to the
> "third party" products,
> why keep them together? 

There are significant, rpm specific, modifications, including:

	1) zlib has splint/doxygen annotations (shrug), and
	has had, and will have again (after the smoke and
	dust of the recent zlib errata has cleared)
		a) a patch to use a whopping big 16MB uncompress buffer
		that leads to (at least, profiled by me) a 10%
		improvement in rpm install time, wallclock metric.
		b) an "rsync ready" patch that, at the cost
		of ~1% in compression size, has a more significant
		(>6%, I have not yet measured) affect on rsync
		download bandwidth. Do a search on "gzip.rsync.patch2"
		for more details.
	For now, zlib in rpm is compiled with -O3 --omit-frame-pointer,
	leading to a slight improvement in performance, but waiting
	for time to finish the above implementations.

	2) db3 (i.e. db-4.0.14) in rpm has a patch that was not included
	in db-4.0.14 that leads to a creepy "Suspiciously high ..." error
	message when using rpm on top of db3. In addition, the db3
	is compiled with "--with-uniquename=_rpmdb" in order to
	prevent symbol collisions when rpm is stacked into, say, some
	Apache -> python/perl -> rpm-{python,perl} -> librpmdb.so
	tool chain.

	3) beecrypt has splint/doxygen annotations (shrug), and
	has a home-rolled, Knuth based, gcd mod invert function to
	work around a bug in DSA signature verification. The problem is
	now "fixed" in (pending) beecrypt-2.3.0, and I'm merging
	changes as rapidly as I can test for breakage with (now
	mandatory in rpm-4.1) rpm signature verification.

	4) libelf-0.8.2 supplies a gelf_foo() API that is not
	widely deployed, even in Raw Hide, certainly not in,
	say, Red Hat 6x.

I hope the above starts to clarify the situation. :-)

So let's get on to your *real* problem, that you can't build
a virgin checkout of rpm-4.1 on non-linux, and have chosen to question
why there's benefit in bundling libraries into rpm instead.

So what's the problem? Bugzilla, please, with details, and I'll try
to get you sorted out.

73 de Jeff

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