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

[Maciej (Matchek) Blizinski]

No dia 9 de Janeiro de 2011 15:25, Philip Brown <phil at bolthole.com> escreveu:
> On Sun, Jan 9, 2011 at 12:38 AM, Maciej (Matchek) Blizinski
> <maciej at opencsw.org> wrote:
>> No dia 8 de Janeiro de 2011 16:38, Philip Brown <phil at bolthole.com> escreveu:
>>>...
>>> 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.
>
> I go by the principle that if something is not constrained by our
> standards, it should then match up what a user of the program expects
> if they install it themselves.  ie:"normal defaults for the program".

Yes, if it's something that our standards don't regulate, it's fine to
rely on what the installer does.  If we talk about a vital element of
our software distribution, we have to set installers aside.

>> 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.
>
> yes it is a hassle... which is why we have symlinks :)
> We are probably long past time of implementing "alternatives" links
> for mysql and postgres, into /opt/csw/bin, at least for the client
> program.
>
>
>> 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".
>
> certainly that is not appropriate. I suppose it would be helpful to
> explicitly call out in this discussion,
> "programs should not be configured with any prefix other than
> /opt/csw, unless there is a compelling requirement to have a
> subprefix". (such as an ongoing need to support more than one version
> of a particular program installed at a time)

Fair enough.  However, even an ongoing need to support more than one
version of a program does not necessarily mean that we need to compile
programs with a different prefix.  Take gettext for example.  If we
applied your logic to gettext, we'd have /opt/csw/gnu/bin with the
utility, and libintl.so.8 would live under /opt/csw/gnu/lib.  But we
didn't do that.  Instead, we used our standard prefix and added a
letter in front of binary's name.  This way, libintl.so.8 got
installed in /opt/csw/lib, which is an excellent place for it to be.

I believe that it's the same with cases such as MySQL and PostgreSQL.
The only conflicting parts are the binaries, and there is a number of
solutions better than using a custom prefix.  A custom library
directory (/opt/csw/foo/lib) is therefore only a side effect of a not
necessarily optimal solution to a technical problem.  That doesn't
strike me as a compelling argument to keep libraries at a nonstandard
location.

What I'm proposing, is that we take the gettext (and coreutils, ggrep,
etc) approach to shared libraries.  Which brings me to the next
point...

>> The following statement still stands:
>>
>> The fact that some users of a common resource are special, doesn't
>> mean that the resource should be.
>
> sorry, I dont think I fully understand what you are saying there.

The general case of the statement probably doesn't need much
explanations.  You don't have separate web servers for Firefox, Google
Chrome and elinks.  Just because one client is special, doesn't mean
you need to make the shared resource special.

In the case of shared libraries, they are the shared resource, and
binaries linking to them are the clients.  Some clients
(/opt/csw/muysql5/bin/mysql) are special, some others, like myodbc or
php, aren't.  The fact that some binaries linking to it live under a
different prefix, doesn't mean that shared libraries need to.

>>> 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.
>
> its not about being self-sufficient. it was most likely about typical
> sysadmin methodologies in deciding what to clean up.
> "Hmm.. this filesystem is way too full. what can I get rid of cleanly?
> lets run du -k"
> Then when you get obvious "big directories" that you are not using,
> you can remove them by "appropriate" means, which may still be
> "pkgrm".  There's probably other reasons lurking... i think I dont
> remember the full reasons.

I feel this branch of our discussion borders on ridiculous, but okay,
let's continue if you wish to.

If you want to cleanly get rid of some files, removing /opt/csw/mysql5
might be a very bad move if libmysqlclient is in /opt/csw/mysql5/lib.
You might have a program you use (say, php5 or bacula, or postfix)
linking against libmysqlclient.  Removing /opt/csw/mysql5 may
effectively disable your website, or mail server, or whatever it is
you're running.  In such scenario, if you insist on it, having
libmysqlclient located under /opt/csw/lib is a better option, because
your web or mail server will continue functioning even after the
removal.