This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RPM and shared library support

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

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 --/


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...


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]