[csw-maintainers] Shared library placement proposal

[Philip Brown]

2011/2/11 Maciej Bliziński <maciej at opencsw.org>:
> 2011/2/10 Philip Brown <phil at bolthole.com>:
>> 2011/2/9 Maciej Bliziński <maciej at opencsw.org>:
>>> 2011/2/10 Philip Brown <phil at bolthole.com>:
>> 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.
>
> Can you provide a specific example?  One piece of software that needs
> an old version of berkeleydb, is postfix.  I've read its build
> recipe[1], which requires two elements:
>
> 1. Include files
> 2. The .so file (with its target)
>
> It does not require anything else.  No other parts of berkeleydb-4.2
> are necessary.

that in itself, should be a sufficient example.
However, I have been told by people who know berkeleydb better than I,
that you also need the version-specific utilities (binaries) because
of differences in the underlying 'database' format between versions.

> This is a non-sequitur.  If file conflicts are present, there are two
> things to be done:
>
> 1. Find out whether older files are actually useful ...

All my comments are predicated with [when it is determined that it is
*neccessary* to have a subprefix].
I am not saying it is always necessary. I am only saying that *when*
it is, that certain things should then be done.
So please stop derailing the discussion by going back to [we 'also'
need to find out if it is neccessary]



>>>> 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"?
>
> It is not possible for me to answer a question framed that way.

meaning, you dont wish to be seen as impolite. But you ARE saying you
dont believe me.


> would like to discuss ideas, not people.
>
>> "I've never seen it" != "it doesnt exist".
>
> Agreed.  The second part of the reasoning is: if it exists, it is
> possible to come up with an example.

Lots of things are "possible", without being easy to do. I've compiled
hundreds of pieces of software. You're asking me to go through all of
them, for the reason that you cant show me professional courtesy and
respect, by taking my word for it that I've hit this?



>> 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.
>
> The argument above sets up and attacks a straw-man.  I'm not
> suggesting anything about a list of approved command line switches.

its close enough. you are at minimum suggesting a list of "approved
tools", outside of which, we should ignore other tools.


> I'm suggesting that if the distribution of disk usage across
> directories under /opt/csw is a factor to be taken into account in our
> policy, it needs to be discussed and agreed on separately, before it
> can be used in policy making.

I think we've wasted enough time in attempting to relegate this to a
side issue. Lets just decide it, and move on to your larger proposal.
Since this is a smaller issue, I think it makes sense to vote to
resolve it, before the larger issue. Particularly since resolution of
it, simplifies debate on the larger issue.

I formally call for the start of the voting process, on the following issue:

"Motion for policy:
 In cases where it has been determined that it is neccessary for a
program to be installed in its own subprefix of /opt/csw, and the
program easily supports some equivalent of
configure --prefix=/opt/csw/subprefix
the program should be compiled as such, and installed as such, with
symlinks being made from important places in /opt/csw/(bin,lib) as
warranted, into the subprefix.

In such cases where the default installation to /opt/csw/subprefix
results in some files being placed non-optimally, it may be allowed to
move around things slightly(ie: setting up isaexec usage), but best
practice is to respect the default installation strategy of the
program when using
 $prefix=/opt/csw/subprefix, as much as possible.
The reason for this is to avoid confusing other programs that may
require it, and may expect the default installation layout
"




Since you are the secretary, I think it is technically your
responsibility to write up this sort of thing and officially put it to
the maintainers list as a separate email?  But if you would prefer I
do it, please say so, and I will do it.
(or are we making Ben the official vote-caller in this board's era?)

I would suggest emailing out the above quoted two paragraphs, putting
a [vote] in the subject line.