[csw-maintainers] Shared library placement proposal

[Philip Brown]

On Wednesday, February 9, 2011, Ben Walton <bwalton at opencsw.org> wrote:
> I think we're spending a lot of time on this discussion for a part of
> the policy that ultimately pertains to a small percentage of our
> packages.

This is certainly true. Unfortunately, see below...

> If we can step back for a moment, lets consider the clean solution to
> this:
>
> ./configure --prefix=/opt/csw
>
> That's right, if we had alternatives in the first place, we most
> likely wouldn't even be having this conversation.

This is not true. So it would seem that you have missed one of the
main points of this discussion.
The issue, about "a small percentage of our packages", is that they
CANNOT be packaged up with prefix=/opt/csw. Even with use of
"alternatives" utils.

This subdiscussion, is only relating to things that MUST have their own prefix.
Certainly, if there are clean ways to compile it and install something
with prefix=/opt/csw we should do so. But we are talking about the
things that cannot.
For example, the multiple versions of berkeleydb. That we have to have
installed at the same time, and use as neccessary. It's not a matter
of "pick this one, to be the 'real/active' one"

>...
>  as Maciej has pointed out, it's
> valid to: ./configure --prefix=/opt/csw/prefix --libdir=/opt/csw/lib.
> One is more normal, agreed, but both are valid.

 In many cases, this works. In very rare cases, it does not. But that
side of things isnt really the important thing here.

What I've written before in this very thread thread, but I guess I
have to repeat now, is that having the library detectable in
$PREFIX/lib is important, not so much for the program itself, but for
*other* programs that need to link with it.
Unfortunately, some software has really dumb configuration. it only allows for
--with-somelib=/install/prefix/here
NOT
 --with-somelib-lib=/path1 --with-somelib-inc=path2 --with-somelib-utils=path3

Not having the shared lib visible in its expected place of
$PREFIX/lib, would require some other programs to be heavily patched
to compile it properly.
So, it needs some kind of presence in *both* /opt/csw/lib and
/opt/csw/PREFIX/lib

So then we come back to symlinks, and which direction they should be.


> If we start considering side effects as weighted factors when setting
> policy, we're doomed.

If everything else is equal, then side effects are then useful to consider.
Functionally speaking,  for achieving the goal of "allow use with
-L/opt/csw/lib", direction of symlinks doesnt matter. At that point,
the lesser side issues are fair play for a decision on which direction
they should go.