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

[Philip Brown]

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


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




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


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