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

[Maciej (Matchek) Blizinski]

No dia 2 de Janeiro de 2011 20:55, Philip Brown <phil at bolthole.com> escreveu:
> Deal with the reasons on their merits, please? Let's have a factual
> comparison of arguments for each way.

Let's start with what shared libraries are and what they are for.
Long story short, they are providing functionality to binaries.  We
have a standard place to keep them: /opt/csw/lib, with optional
subdirectories for additional architectures, if necessary.  When
compiling new software, we're using the standard flags: -L/opt/csw/lib
-R/opt/csw/lib which link against libraries in /opt/csw/lib and set
the RPATH to look there.

In principle, we could put shared libraries anywhere, but we wanted to
make our lives easier and chose to have a standard place for them.

There are some shared objects which are not public shared libraries;
for example Kerberos ships libraries against which Kerberos binaries
link, but other binaries don't.  Therefore, we need to distinguish
between private and public shared libraries.

What should be the criteria for public shared libraries placement?  If
we chose to have a standard place, we should stick to it.  Public
shared libraries should be put under /opt/csw/lib, because only then
they will be found during linking, without tweaking any environment
variables and/or linker flags.

Shared libraries have the status of a common resource, and once put
into place, they serve many binaries and many packages.  The original
software that put them in place doesn't matter that much, because once
any other package starts to link against them, they have to stay in
place until the dependent binary goes away.  The original package that
provided them might even go away, but shared libraries have to stay.

Taking all that into account, the packaging of shared libraries should
be mainly driven by thinking about how these shared libraries are used
by other packages and how well they integrate with the rest of CSW
ecosystem.  For example, a shared library under a custom prefix is not
necessarily a good idea, because all programs that need to link
against it, have to have a nonstandard RPATH, and the linking phase
has to use nonstandard linker flags.  For the sake of other
maintainers, and us ourselves, we should place public shared libraries
under /opt/csw/lib, and nowhere else.

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, but do we do that in other packages?  We don't, we place the
actual files directly under /opt/csw/lib.  It's true that MySQL
executables are under /opt/csw/mysql5, but it's an exception rather
than a rule.  If it was possible to keep these binaries directly under
/opt/csw/bin, they would be kept there.

MySQL binaries under /opt/csw/mysql/bin do not have their own shared
libraries; they use a common resource, even though the common resource
happens to be build from the same source tar file.  Packages providing
the MySQL shared libraries should be created according to the general
rules of packaging shared libraries, and the rules is that you put
them under /opt/csw/lib.

Does it sound like a good reason?