[csw-maintainers] Packages with private /opt/csw/foo directory

[Philip Brown]

On Fri, Nov 6, 2009 at 2:43 AM, Maciej (Matchek) Blizinski
<maciej at opencsw.org> wrote:
> ...
>
> I would like to rant a bit more about the nonstandard prefix.  ..
>
> /opt/csw/lib/mysql --> ../mysql5/lib/mysql
> /opt/csw/include/mysql --> ../mysql5/include/mysql
>
> If mysql4 does the same, the two packages can't peacefully coexist. If
> mysql4 does not install the /opt/csw/lib/mysql symlink, why has mysql5
> to?
>

I think the idea there was that mysql5 was officially the "default mysql".
That being said... we should probably discuss further, possibilities
of more default mysql "presence" in the top level $PREFIX=/opt/csw
style.
And how to implement that.



For example, while the back end DATABASE ENGINE, probably is best off
in separate prefixland, client-side things are relatively binary
compatible (or are they?)

at the very least, having /opt/csw/bin/mysql (the client)  ->
/opt/csw/mysql5/bin/mysql is probably pretty safe.

There can then be questions about whether symlinks for libraries in
/opt/csw/lib would be appropriate.

And then the question of whether to implement the links in the
mysql5(_client/_rt) packages, or whether to have a "metapackage".




> My way of thinking would be: There should be one canonical MySQL
> version for OpenCSW, which is being installed in /opt/csw. If there
> are other versions, say, legacy versions, they can be installed in
> different prefixes, but they are not allowed to install anything that
> conflicts with the canonical package.
>
> Having said that, I am going to continue to use /opt/csw/mysql5 for
> the mysql5 package.

Good :)
Because handling renames/relocations, when things are not properly
binary compatible, is a nightmare.