Since you asked for others opinions...
I think you should not fight the standard configuration of packages when
they expect to use shared libraries. I am just starting to use openpkg and
already I ran into conflicts with two packages because of the restriction on
shared libraries. Maybe I just picked unlucky first attempts. Postgres is
broken in openpkg 1.2 - missing shared libraries that it references
internally. Postgres supposedly supports all static (--disable-shared)
builds but that also fails on my builds and maybe doesn't quit fit the
openpkg policy anyway (you mention that you want to use system shared
libraries and maybe that setting disables it). Python prefers to use all
shared libraries for its modules. They strongly advocate against
incorporation of static libraries into binary modules as it means the module
cannot be shared (in memory) across processes (as it is not PIC). If you
want to go ahead and use static libraries in your modules you have to hack
the build process (to be fair - this problem in python went away when I used
binutils as recommended by openpkg).
GUI desktop projects desperately require shared libraries across packages.
Unless maybe you make the entire GUI system one package. This would be like
the old sun tools GUI appications where every GUI app was actually linked
into a single executable. Weren't GUI's the driving reason for shared
libraries? I bet that is the reason the other Martin is pressing for them.
While there are other benefits I am finding from openpkg the one reason that
made me give up my homegrown packaging system was the promise of using other
peoples build scripts instead of writing them all myself (or the promise of
sharing the ones I write). I fear that the restriction on shared libraries
may hamper the vision by placing an unnecessary burden on creating these
scripts.
Managing the accurate linking of libraries is probably the biggest headache
in building reliable software from source, but you correctly state that
shared libraries are mostly independent of this problem. People always need
to carefully manage their paths. I think you worry too much about the exotic
case of multiple openpkg installations in use at the same time. I think that
will be quite rare for most users. When they do - they will have to be very
careful. They will have similar problems even with finding the correct
executable in PATH ("finding the right perl" is a favorite game in my
environment). While I can envision the occasional need for an indirection
scheme that forces LD_LIBRARY_PATH with wrappers I would not make it
integral to openpkg. Please. I strongly dislike reliance on wrappers for
packaging and it was a selling point to me that openpkg does not rely on
them currently.
That said I am still really happy with openpkg. Keep up the good work.
Martin
----
Martin Andrews
[EMAIL PROTECTED]
> -----Original Message-----
> From: Ralf S. Engelschall [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, February 15, 2003 1:25 PM
> To: [EMAIL PROTECTED]
> Subject: Re: OpenPKG and static linking
>
>
> On Sat, Feb 15, 2003, [EMAIL PROTECTED] wrote:
>
> > [...]
> > o the resulting binaries are still not portable between
> different versions of
> > the OS due to the fact that not all libraries are static.
...
>
> What is the opinion of others on this subtle "dynamic shared libraries
> in OpenPKG" issue?
______________________________________________________________________
The OpenPKG Project www.openpkg.org
Developer Communication List [EMAIL PROTECTED]
