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

[Maciej (Matchek) Blizinski]

No dia 8 de Janeiro de 2011 16:38, Philip Brown <phil at bolthole.com> escreveu:
>>>> 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]

I know what you mean, I was asking why you use the installer as a guideline.

>> 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 have a prefix, and it is /opt/csw.  Any other private prefixes, are
just the easiest way of getting around installing two versions of the
same software.  The easiest doesn't mean the best, though.

As an OpenCSW user, I perceive using /opt/csw at times, and
/opt/csw/mysql5 at times, and /opt/csw/postgresql at times, as an
inconsistent handling of files.  It's enough hassle to integrate one
prefix into your system - you need to set PATH, and think about that
prefix potentially affecting shared library linking in your programs,
about conflicting paths, etc.  Adding even more prefixes is in my
opinion counterproductive.  The consistency of prefix means that
OpenCSW software gets packaged under /opt/csw/{bin,lib,share,...}, and
nowhere else.

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

Agreed. (With 'potential' also meaning 'reasonable'.)

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

Standardized linking is one of the goals, and symlinks meet that goal,
that's right.  A bigger goal is to achieve a standard filesystem
layout.

The reason to insist is that our file placement policy is not "place
your files wherever you like, just make symlinks at the right
locations".

If a library is accessible at /opt/csw/lib (via a symlink or
otherwise), why multiply entities beyond necessity?

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

This has never been and never will be the case.  For example, binaries
at /opt/csw/foo/bin will always need shared libraries from
/opt/csw/lib.  Any scripts will need interpreters from /opt/csw/bin,
basically - no /opt/csw/foo can live without /opt/csw.

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

You must be easy to annoy...  I don't know what would be your goal
behind "du -k /some/prefix", but I suspect it would be hard to defend
as a basis for OpenCSW filesystem policy.  If there's any prefix you
might be interested in measuring, it's /opt/csw.  Any other /opt/csw
based custom prefixes will never be self-sufficient.

The following statement still stands:

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