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

[Philip Brown]

On Sat, Jan 8, 2011 at 7:24 AM, Maciej (Matchek) Blizinski
<maciej at opencsw.org> wrote:
> No dia 7 de Janeiro de 2011 03:53, Philip Brown <phil at bolthole.com> escreveu:
>
>> 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. ...
>> If we haven't made a decision regarding shared
> libraries, let's take a look at this issue now.

I agree, now seems like a good time to examine this


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

By that I mean [naturally generated there by the program's
config/installer, if we do nothing but specify
--prefix=/opt/csw/subprefix]


> Isn't it better to think of shared libraries as a shared resource,
> without obscuring the logic with prefixes?

I think this is an area where we have two "valid" ways of proceeding
-- valid in the sense of "can be considered a consistent methodology"
at least -- and so this issue becomes a little more flavored by
"taste" vs purely technical.

Certainly, it is "consistent" to declare "all 'public' linkable shared
libraries must be in /opt/csw/lib directly".
But it's not particularly beneficial, beyond a trivial goal of robotic
consistency. and it blocks other goals.
Such as, consistency of prefix.
Some types of consistency are mutually exclusive. For example, the
consistency of,
"If a program, or program suite, has been sub-prefixed, then all
(non-dynamic) files for it should live under that subprefix".
This is a reasonably expected, even presumed consistency by a user.
We're going to have to break one set of consistency rules, one way or
another. So proceeding merely on "must keep things consistent" is
inadequate.
It seems to make more sense to determine this issue based on potential
benefits/goals.

more lower down.


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

well, I agree to the extent that I think it may make life easier to
have "something" in /opt/csw/lib for them.
We just differ in that I think the "something" should be a symlink :)


Maciej, it sounds like you are mixing goal objective, with implementation.
Isnt your real goal, "to have standardized linking, -R/opt/csw/lib
whereever possible"?
Why not just say "okay symlinks meet that goal", without insisting it
also be done by your preferred methodology?


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


okay, back to listing potential target "goals" for library policy.
Someone, perhaps you, mentioned something earlier about everyone using
packages as a delivery system.
What you might not consider, is that the packages can be a "one-time"
delivery system only.
Some people run a package update once a year, and then forget about packages.
Or, have "the sysadmin group" install packages, but they themselves
know *nothing about packages*.
Or, the packages may have been delivered to a template system, which
is then filesystem-level duplicated in a sort of production line
methodology, and targets know nothing about packages.
Or, /opt/csw may be shared/duplicated out by other methods, and again,
the target systems know nothing about packages.

In all these kinds of situations, to help our users have an "easy to
use" experience, we need to make sure our deliverables make sense on
purely a filesystem basis.
The users probably care nothing about linking. They just want things
to be consistent from *their* perspective.
I would argue that from that perspective, "everything associated with
/opt/csw/foo, 'lives' under /opt/csw/foo", is the most consistent. and
helpful.
I myself have done a quickie "hmm, wonder how much stuff is under
there? du -k /some/prefix"  and then been **really annoyed** when I
found out later, that not everything was in there.
This is real world stuff, not just random hypotheticals I'm tossing around.