[csw-maintainers] Shared library placement proposal

[Maciej Bliziński]

2011/2/10 Philip Brown <phil at bolthole.com>:
> This subdiscussion, is only relating to things that MUST have their own prefix.

I am not entirely sure whether any software actually requires being
compiled with a custom prefix.  It's quite likely that every package
currently compiled with a custom prefix, could be in fact compiled
with --prefix=/opt/csw.  Other steps can be taken to ensure
compatibility with other versions of the same piece of software.

> 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"

Are there two incompatible libdb-X.Y.so files with the same SONAME?
If the answer is no, then BerkeleyDB can be compiled with
--prefix=/opt/csw.

>>...
>>  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.

By $PREFIX, do you mean our prefix, or a different one?

> 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

I highly doubt this is the case.  I haven't seen an example of source
code which, configured with --prefix=/opt/csw, requires a library to
be in /opt/csw/foo/lib, and can't be linked when that library is
available through /opt/csw/lib.

When a library is present in /opt/csw/lib, and the running binary
contains /opt/csw/lib in RPATH, the library will always be found.  All
our binaries have /opt/csw/lib in RPATH, therefore all libraries in
/opt/csw/lib will always be found.

If there is a binary that needs OpenCSW libraries and does not have
/opt/csw/lib in RPATH, it's a bug, right?

>> 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.

While I agree with the general statement that if larger criteria are
equal, considering smaller criteria is useful, I believe that the
smaller criteria should be within the scope of our goals as the
project.  The output of "du -k" is not within OpenCSW's goals.  If you
would like to include the output of "du -k" in our policies, the
proper way to do this is sending out a proposal.