[csw-maintainers] Shared library placement proposal

[Peter FELECAN]

Philip Brown <phil at bolthole.com> writes:

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

What you describe it's folklore, myths and legends, not a real example.

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

I'm saying that I don't believe you. I will believe you when you give a
concrete example and not some folksy reminiscences.

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

Nobody asks you that. What we ask is a concrete example.
Respect and courtesy are not arguments by themselves.

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

Nobody has suggested something like that. This is a distortion of
reality.

-- 
Peter