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 wrote:
On Fri, May 09, 2003 at 12:02:50AM -0400, Charles Wilson wrote:

Nicholas Wourms wrote:

[Actually, I wrote the following paragraph, not Nicholas -- DA]

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

It's actually like this:

libbz2--/        \                 /  |
                  \               /   |
                   +---librpmdb--+    /
                  /                  /

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.

Well, from the looks of it, we'll have to have shared libraries for
libbz2, libz, and libpopt first before I can release an rpm-devel

Yup. However, later on we can work on getting rpm to use the default libdb4.

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

OK, so now it looks like rpm-devel will only need shared libs for libbz2
and libpopt.

Ok, sorry Chuck, I forgot... Anyways, I'll fix up a proposal and explination to satisfy your concerns. Then we can debate the finer points of the code to your satisfaction.

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.

Yes... Yes... I know, I had a longer timetable in mind, though.

I don't quite understand this comment; do you mean that we don't need rpm-devel? Actually, I'd like to see it released soon myself. I'm deferring work on an apt-rpm port until the libbz2/libz/libpopt shared lib situation is resolved for rpm-4.1. Does strategy actually make sense?


I really hope this doesn't annoy Nicholas, but I'm prepared to volunteer
to crank out the next release (1.7) of popt, just so I can get my hands
on the libraries I'll need to push rpm-devel out the door, which in turn
will allow to me to move forward with an apt-rpm port.

Actually it does annoy me, but since you are so pell-mell to get it out the door, I'l go ahead and fix up the packages for release this afternoon. Ok?


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