On Sat, Jul 19, 2003, Matthias Kurz wrote:

> > Would patches that implement (as options, turned off by default) shared
> > libraries and relocation be acceptable?
> >
> > I'm in a situation that I need those features, but dread having to fork
> > a set of package spec files etc. for my own use.
>
> I think, the shared library "problem" needs to be addressed some day,
> anyway. What are there for known problems ? I think uncontrolled
> dependencies (automatically picked up shared libs) are the greatest
> problem, aren't they ?

Some of the reasons are mentioned in the FAQ AFAIK.

> Instead of patching all the many spec-Files that have "disable-shared"
> set etc., wouldn't it be possible to introduce a global setting (with
> a default of "no").

Yes, I plan for a with_shared option which all packages can support.
The question which is still unanswered is _HOW_ the packages should
support this. At least without executable wrappers this option at
least disallows multiple OpenPKG instances on the same machine. But
that certainly has to be the price for using shared libraries. The
only workaround on ELF platforms is that we either patch all packages
to correctly supply an -rpath to hard-code the paths to the shared
libraries or write a little utility which post-adjusts installed
libxxx.so files and hard-codes their path. The whole shared library
issue is on the TODO list for OpenPKG 2.0.

                                       Ralf S. Engelschall
                                       [EMAIL PROTECTED]
                                       www.engelschall.com

______________________________________________________________________
The OpenPKG Project                                    www.openpkg.org
Developer Communication List                   [EMAIL PROTECTED]

Reply via email to