[csw-maintainers] Shared library placement proposal

[Philip Brown]

2011/2/9 Maciej Bliziński <maciej at opencsw.org>:
> 2011/2/10 Philip Brown <phil at bolthole.com>:
>> 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"
>
> 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.

sigh.

Certainly the thing "can be compiled" that way. The problem is that we
need the FULL environment, to actually use it to compile things that
need it. Some "newer" progams, need "older" versions, not just "the
latest version" of berkeleydb.
 We need the binary utils, and include files, etc. for that version all present.
We need multiple versions installed, at the same time.
They CANNOT co-exist in the same namespace, there are conflicts for
almost every filename.
Therefore, they must be delivered in their own subprefix.

That being the case, either the maintainer has to do all kinds of
fancy post-build scripting to install the stuff expecting to be
installed directly under /opt/csw....
Or they can just do the straightforward thing and compile with
 --prefix=/opt/csw/berkeleydb-X

I would submit to the readers, that the latter is far saner.

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

csw/subprefix.


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

Maciej, I'm not just talking hypothetically, I've SEEN this happen. to
my great irritation. with multiple pieces of software.
Are you going to take my word for it, or are you going to call me a
liar by insisting I provide "proof"?

"I've never seen it" != "it doesnt exist".


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

you have no right to make that statement. Plus it is provably false anyway.
If something is a common user behaviour in Solaris, then it is "within
opencsw's goals" to support it, since our documented goals are to
provide "a straightforward, easy-to-use experience for the user"

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

This is ludicrous. you are setting up absurd hurdles specifically
targetted to justify you ignoring this issue, with no other benefit.

To treat it equally and fairly, would mean we would have to generate
an "officially approved list of user commands, with all 'approved'
command line switches".
 And then if a user said, "well I use that command, with this other
switch", the maintainer could say "well sorry thats not on our
approved user command list, goodbye", which would be equally heinous.