In article <aalcrv$1r35$[EMAIL PROTECTED]> you wrote:
> Doesn't OpenPKG separate the file for development from the present package
>composition? .
> I think that a header file and a library file are unnecessary at the time of server
>management.
Currently OpenPKG does not separate a package into sub-packages via
%package (that's the technical feature you are talking about). The main
reason for this is that (if done consequently throughout all packages) it
leads to a dramatically larger number of packages. And until we have our
OpenPKG RPM frontend available (on which we are slowly working, too) this
quickly becomes a nightmair for the administrator. Because usually you do not
want to just split into runtime/development sub-packages, but also into
client/server, etc.
Additionally I dislike RPM's way of dealing with those
%package stuff in the .spec file, because one has to at least completely
repeat the description if one wants a reasonable one for each package.
So if we use %package we also would like to patch RPM to smooth
this a little bit more.
For all those reasons whe decided to not use sub-packaging until OpenPKG 2.0.
> Moreover, why does not use a share library?
> Suppose that a security hole like zlib occurred.
> In this case, a maintenance becomes complicated.
Another good question in the same direction. You are right that it gets
easier in upgrading. Also you need less disk space, etc. Unfortunately
shared libraries also have their disadvantages. Mainly you need correct
run-time environment (ldconfig, LD_LIBRARY_PATH, etc.) which makes sure
that both the shared libs in OpenPKG and the underlying Unix system do
not conflict and that the libs inside multiple OpenPKG instances do
not conflict. Without wrappers or at least working support for ld's -R
option around applications this very quickly gets very complicated to
solve.
An example: you have FreeBSD and OpenPKG instances under /usr/opkg,
/e/openpkg/sw and /e/ossp/sw, etc (as it is the case for one of
our machines). If OpenPKG would use shared libraries in the "zlib"
package you would end up with libz.so in all those locations.
The Unix loader usually knows only three ways to locate them: a
system-wide configuration (ldconfig,...), a session-wide configuration
(LD_LIBRARY_PATH, ...) and a hard-coded one (ld -R, libtool -rpath,
etc). The first two make you lots of problems, because they search
a path and take usually the first libz.so they find. But they are
available everywhere. The last one is the best solution for the
situation, but unfortunately is not available on all platforms. And
even if it is available, _ALL_ packages have to use the correct linker
options to use it, which in turn means that all non-libtool based
packages have to patched manually by us.
Because of this we decided to still stay out of the shared library
business. We will only go this way if we find that all important
platforms have support for hard-coded paths (because it's the only
reasonable solution to solve the multiple instance problem) _and_ we
find time to adjust all involved packages to correctly use this. The
second usually is very time-consuming, but perhaps someone contributes
all the necessary patches...
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
The OpenPKG Project www.openpkg.org
User Communication List [EMAIL PROTECTED]
