RPM and shared library support

[Charles Wilson]

Nicholas Wourms wrote:

>> Bottom line, folding in subordinate shared library support to the
>> upstream RPM 4.x release might take a while. So, the question
>> becomes: can we move on to shared RPM development libraries
>> (/usr/lib/librpmdb*.dll) without support for subordinate shared library
>> support?

Q: Does librpm access any runctions in the supporting libraries, or is 
librpm independent of them -- and the dependency is derived from rpm.exe?

That is, which is the correct dependency graph:

libz     --\
libelf   ---\____librpm----rpm.exe
libdb    ---/
beecrypt --/


or

librpm   --\
libz     ---\
libelf   ----+ ----- rpm.exe
libdb    ---/
beecrypt --/

If the former, then no -- you need to have DLL versions of the other 
four libs before you can build a shared librpm.  If the latter, then yes 
-- librpm is independent of the other four.

There are obviously other dependency trees that fall somewhere between 
these two extremes.

> I've already done it (modified the 4.1/4.2 builds to use external shared 
> libraries).  The plan is to add rpm's enhancements to each of those 
> packages.  The only thing we need to do is convince CGF to merge the 
> zlib patches, which I see as "harmless" additions anyhow, and we should 
> be set. 

Errm, hello?  I'm the maintainer of the zlib package.  (cygwin dll 
itself contains its own implementation of zlib, but it doesn't export 
the functions).  Anyway, I'm VERY leery of modifying such a fundamental 
library on which so many other packages depend.  I'll need lots of 
handholding and convincing to fork from the official 1.1.4 sources...

> There is no reason to distribute redundant dlls, especially 
> since it sort of contridicts the point of using dll's in the first place.

There are two reasons for DLLs -- one is, as you say, sharing code 
between multiple apps.  The other is to enable slip-streaming updates 
(provided the API doesn't change).

Distributing cygz.dll and cygrpmz.dll violates the first reason -- but 
not the second.

> I've already had one-on-one conversations with Jeff Johnson, and he's 
> filled me in on the nitty-gritty.  As I stated before, there's no rush 
> and I think we can get shared lib support in the next version of rpm.

One step at a time.  And I really think the rpm-devel/GPL issue is a red 
herring: we distribute the source (in -src.tar.bz2) for all the binaries 
that we distribute.  So what if we don't distribute all of the binaries 
that would be produced by a full build of those sources?  That has no 
GPL implications.  Or if it does, I'm in deep kaka -- I don't distribute 
the test apps that are build in libz: minigzip.exe & friends...

--Chuck