"Ralf S. Engelschall" <[EMAIL PROTECTED]> writes: > On Wed, Aug 25, 2004, Simon J Mudd wrote: > > > I've been comparing some OpenPKG rpms against rpms from other RPM > > distributions. One thing I hadn't noticed before is that (at least with > > Postfix) the resultant binary packages are much larger than their native > > equivalents[1]. This appears to be due to the fact that many libraries > > are "mainly" statically rather than dynamically linked. Is this > > intentional? > > Yes, we use statical linking for maximum portability reasons > and to be able to support multiple instances.
ok. Understood. > > This can make a large file/memory usage difference especially for long > > running server processes which use multiple instances (apache?). > > No, this is not quite correct. It makes a difference, yes. But > especially not for server processes with lots of childs like Apache. > Because modern Unix have a clever enough VM subsystem which uses > copy-on-write semantics when fork(2)ing processes. So there is usually > no dramatic physical memory consumption between a dynamically linked > Apache and a statically linked Apache. Keep also in mind that we do no > full statical linking. We just link the OpenPKG parts statically, libc > and other vendor libraries are still dynamically linked, of course. Yes I had noticed the difference in the library dependencies on both FreeBSD and Linux (rhel3) and see that libc is still dynamically linked. While I agree that the vm subsystem will help will multiple instances of the same process, I assume that a busy server with many different OpenPKG processes will have a larger memory footprint than if it used the native dynamically linked libraries. Perhaps the disk space issue is more of a potential problem if all RPMs are installed, but maybe few servers are likely to be installed/used that way. > The issue is just portability and support for multiple instances. > > > Is it possible to enable/disable this behaviour either at a package or > > system level, and if not would it be interesting to be able to configure > > this sort of functionality? Perhaps doing this generically on different > > platforms makes this task much more difficult. > > Yes, the cross-platform support makes this rather difficult. We have > since a longer time plans to build our packages dynamically against > our libraries, but until we can easily solve the multiple instance > problem we certainly will not go this way. The disk space and RAM space > consumption is harmless, because disk space is cheap and RAM space is > not really wasted as I explained. The only real drawback currently known > to me is security updates (see current "zlib" security advisory) which > require more packages to be rebuilded than people usually like. So while it might technically be possible to dynamically link to the specific OpenPKG dynamic libraries, if they existed, the practicalities of this are that it is difficult to do cleanly and on all platforms without spending a lot of time "fixing" the build procedures? Thanks for clearing this question up. Would it be useful to mention "how" the RPMs should be built on the web site so that any new contributors know that the packages must be built a certain way before being acceptable? Also perhaps an indication of the size of the complete SRC and supported binary RPMs for each release? Your documentation mentions the space needed to bootstrap openpkg, but not about maximum space used, information which may be useful for planning. Thanks again. Regards, Simon ______________________________________________________________________ The OpenPKG Project www.openpkg.org User Communication List [EMAIL PROTECTED]
