[csw-maintainers] MySQL shared libraries - how about /opt/csw/lib?

Maciej (Matchek) Blizinski maciej at opencsw.org
Sat Jan 8 16:24:18 CET 2011


No dia 7 de Janeiro de 2011 03:53, Philip Brown <phil at bolthole.com> escreveu:
> On Thu, Jan 6, 2011 at 5:12 PM, Maciej (Matchek) Blizinski
> <maciej at opencsw.org> wrote:
>> No dia 2 de Janeiro de 2011 20:55, Philip Brown <phil at bolthole.com> escreveu:
>>>
>> You can say that it's enough to place a symlink from /opt/csw/lib to
>> another place that contains the binary file and programs will work -
>> fine,
>
> and that is indeed my position
>
>> do we do that in other packages?  We don't, we place the
>> actual files directly under /opt/csw/lib.
>
> and that's not really any kind of deliberate decision or policy, but
> merely a convenient side effect of
>  --prefix=/opt/csw
> for MOST packages.

Deploying a vital component of the csw ecosystem based on a side
effect doesn't sound like a good idea.  Just like you don't change
things in packages just because checkpkg said so, you don't plan your
layout just because the install script happened to put them there.
Quite often the result of install script's work will be aligned with
what we won't, but this is a convenience rather than a good way to
create packages.  Ultimately, files end up at the locations of our
deliberate choice.  If we haven't made a decision regarding shared
libraries, let's take a look at this issue now.

> however, for packages where prefix != /opt/csw, we dont always do that.
> (in fact, I think we RARELY do that)
>
>
>
>> It's true that MySQL
>> executables are under /opt/csw/mysql5, but it's an exception rather
>> than a rule.
>
> Yes, this is exactly my point. programs with their own sub-prefix are
> special. Perhaps we should make a specific variation on our standards,
> for programs with sub-prefixes.
> Something like, "if shared libs are generated under $PREFIX !=
> /opt/csw, it is recommended
>  to create a symlink in /opt/csw/lib, pointing to the appropriate library"

Why are you thinking in terms of "shared libs are generated under"?
Isn't it better to think of shared libraries as a shared resource,
without obscuring the logic with prefixes?

> I will also point out, that our berkeleydb packages also keep their
> shared libs under their own subprefix, rather than keeping the actual
> .so files in /opt/csw/lib

My personal opinion is that this is a suboptimal layout.  Just that we
used to do something doesn't mean that it's the right thing to do.

>> MySQL binaries under /opt/csw/mysql/bin do not have their own shared
>> libraries;
>
>
> ahh.. actually, many of them use libmysqlclient.
>
> Perhaps you did a check "ldd /opt/csw/mysql/bin/*", but forgot they
> are using isaexec?
>
> but if on other hand you check like this...
>
> bender$ ldd /opt/csw/mysql5/bin/sparcv8/mysql|grep mysql
>        libmysqlclient.so.15 =>
> /opt/csw/mysql5/lib/sparcv8/mysql/libmysqlclient.so.15
>
>
> Perhaps you meant they do not use "private" shared libraries?

Yes.

What I meant is that they use libmysqlient, and that libmysqlclient is
not a private, MySQL's own thing, but rather a public, common
resource.  It's indeed used by MySQL executables, but not only.  There
are other executables that also use them.

The fact that some users of a common resource are special, doesn't
mean that the resource should be.


More information about the maintainers mailing list