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.
> 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.
> Perhaps the issue is ensuring native libXXXX libraries do not configure
> with OpenPKG installed equivalent libXXXX libraries?
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.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
The OpenPKG Project www.openpkg.org
User Communication List [EMAIL PROTECTED]
