[csw-users] Selecting 32 or 64 MySQL server

[Laurent Blume]

Hello all,

I've got a simple questions, but it seems there is no simple answer yet, 
so I'd like for some feedback first.

Problem is simple: both the 32- and 64-bit MySQL servers are delivered 
by OpenCSW. How to select one?

This is very much Solaris 10-centric. I really assume here that S9 and 
below are dead or deadish, and not really worth bothering about anymore.

The current method only point to the 32-bit one. There is no mechanism 
yet to select the other one.

Here are the choices I've thought about:
   (1) Get rid of the 32-bit version altogether: seriously, this is my 
preferred way. Solaris 10 supports 32-bit only on x86, and that kind of 
hardware is seriously outdated by now. Replacing it seems trivial;
     Pros: Simple and results in less work
     Cons: Might not be possible, or not useful for all other daemons

   (2) Use a central or specific configuration file, user-edited, to get 
the desired value: MySQL5's method already sources a mysql5rc file at 
different locations. It could contains a variable such as 
MYSQL_ARCH=[32|64|amd64|sparcv9|...], that could then be used below to 
start the daemon:
     if [ -n "${MYSQL_ARCH}" -o "${MYSQL_ARCH}" = "32" ]; then
       ${BINDIR}/${MYSQL_ARCH}/mysqld_safe ...
     else
       ${BINDIR}/mysqld_safe ...
     fi

     I believe this could be extended easily to any other daemon by 
sourcing /etc/opt/csw/csw.conf, and using, if any, the DAEMONNAME_ARCH 
variable found there (or ${pkgname}_arch?)
     Pros: Easy to select and provide a list of defaults for, either in 
a sample csw,conf file or in daemon-specific rc files, and will be kept 
easily across upgrades; default could easily be set using isainfo -b; it 
would also allow to have different optimization levels, if ever needed;
     Cons: Well, there's the need to create and maintain sample files, 
and to modify existing methods

   (3) Use isaexec
     Pros: Transparent, no configuration needed
     Cons: I've been told Dagobert has 1001 reasons not to use it, I 
guess one of them is that when it's actually needed to select a specific 
version, then it's not easy at all

   (4) Use an SMF property;
     Pros: It's SMF! It's made with XML! Oracle likes to put everything 
there!
     Cons: Same as Pros, plus it needs to be handled properly by the CAS 
stuff so it's kept across upgrades.


In a pinch, I'd favor (2), since it covers more than just my MySQL problem.

Thoughts?

Laurent