[csw-maintainers] Shared library placement proposal

[Maciej Bliziński]

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

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.

It's just one example though, so I'd be interested if there is a piece
of software which requires more than the two elements listed above.

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

Yes, there are filename conflicts.

> Therefore, they must be delivered in their own subprefix.

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
2. If they are, either put them in a separate directory, or modify
file names to remove conflicts

Delivering in a custom prefix is a way of accomplishing point 2, but
it's not the only way.

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

There are two sides to it: building the library (say, berkeleydb) and
building software that links to it.  It may be easier to build
berkeleydb itself with a custom prefix, but it makes it harder later
on, for other maintainers to build software linking against 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
>>
>> 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.  I
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.

I believe it makes sense to examine evidence before forming an
opinion.  It would help to provide a scenario in which there's a need
to provide a library outside of /opt/csw/lib even though it is already
available in /opt/csw/lib.

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

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

Maciej

[1] http://gar.svn.sourceforge.net/viewvc/gar/csw/mgar/pkg/postfix/trunk/Makefile?view=markup
    Lines 181-185
[2] http://lists.opencsw.org/pipermail/maintainers/2011-February/014094.html