Registry redirection was improper and hence not able to pick the value for the OLDERVERSION property. as a result in the install upgrade dialog null value wa being passed.
Cross-upgrades between GPL and commercial versions should be allowed by
the MSI package even when both packages are the same version.
Fixed by allowing upgrades to the same numeric version.
Currently MySQL MSI installer on Windows installs MySQL in
"per user" mode. It means that if a Windows machine has
multiple users, they each can install MySQL independently.
However the default path of MySQL is "C:\Program Files (x86)\MySQL\"
and when two users install MySQL on same machine, the installation
by second user just overwrites the MySQL files. This default shared
location leads to the issue where if the second user uninstalls MySQL,
the installation files are removed for the first user as well.
In this fix, we are now making the default installation "per machine".
It means that when MySQL is installed with defaults options, all
users can see the shortcuts for MySQL in start menu(since installations
is for all users). Also when any user relaunches the installer, it will
consider that action uninstallation rather than installation for that user.
There are command line options in installer that can be used to undo the
"per machine" installation but will not consider that scenario.MySQL
is a server product and it does not make a lot of sense to install it
differently for each user.
Bug #15972480
This is the change for 5.5:
a cleanup in the way "libmysqld.so" is created.
(Patches were adapted for 5.5 previously.)
Originally, the ".so" was created by taking all modules in
"libmysqld.a", after removing some few which caused unresolved
references.
This is no good idea, rather "ld" should be used to follow all
references from some few start modules.
At the same time, the ".so" version needed to be corrected:
The original "0.0.1" is both wrong and risky.
Rather, the server version is used to identify the ".so" file,
but for linkage the first two levels are sufficient (so upgrades
are possible without re-building the embedded application).
The patch "mysql-chain-certs.patch" needs to be adapted
to code changes in "vio/viosslfactories.c" which were
done in MySQL 5.5.
Then, the patch can be re-enabled in the spec file.
A change to "vio/viosslfactories.c" in August, 2012,
broke a patch which is to be applied during the build
of ULN RPMs.
The patch file is
"packaging/rpm-uln/mysql-chain-certs.patch"
This change bypasses the problem by not trying to apply
the patch.
This is a regression and must be fixed, not bypassed.
