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

[Philip Brown]

On Sun, Jan 9, 2011 at 2:33 PM, Maciej (Matchek) Blizinski
<maciej at opencsw.org> wrote:
> No dia 9 de Janeiro de 2011 15:25, Philip Brown <phil at bolthole.com> escreveu:
>>
>> 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.


I agree. Rather than quoting the next chunk of your email, I'll just
say feel free to make the language about "compelling requirement"
tighter.
Certainly, there are some programs that can cleanly support multiple
versions installed, without subprefixes. Then again, there are others
which do not.



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

Interesting that you bring up firefox. Because is another thing that
effectively "has its own prefix", with symlinks from /opt/csw/bin so
users don thave to tweak their path.
[well okay its a wrapper script not a symlink :) but same principle.
All the real libraries live under the firefox prefix]


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

I explicitly said in my message (which you even quoted), that in such
an instance, I may use pkgrm to remove the files.
For initial diagnosis/investigation, sometimes it's nice to be able to
use "normal' filesystem tools rather than pkg ones, even if actual
file add/removal is handle by pkg tools.
So in that case, user would get a warning on pkgrm that something else
is using it.


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


contrariwise, if someone discovers that they are using the shared libs
from mysql, they will probably find it useful to have the client
around for debug/admin purposes. It then becomes a slippery slope
down,
"well, we have the 'real' shared lib in /opt/csw/lib, so lets have the
'real' client prog in /opt/csw/bin"....

On the other hand, if symlinks are good enough for the client prog
that is sub-prefixed, it should be good enough for the shared lib that
is sub-prefixed?
There's the other side of the consistency sword.