Details
-
Task
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
None
Description
MariaDB 5.5 RPMs are based on OurDelta's 5.1/5.2/5.3 RPMs.
This worked pretty well for RHEL5/CentOS5.
In RHEL6 MySQL packaging was significantly changed and our 5.5 RPMs don't install anymore.
Packaging needs to be fixed to work with RHEL6.
Possibly, we might need to split RPMs to be smaller and more fine-grained.
See attached spec files from Mageia and CentOS6.
Here is the problem.
Vanilla CentOS 6 has Postfix installed by default.
Postfix needs mysql-libs.rpm. And not just any mysql-libs, but libmysqlcient.so from 5.1. We can hack around and provide/obsolete mysql-libs in our RPMs. But we cannot build 5.1 shared libraries from a 5.5 tree.
So, to install MariaDB 5.5 on CentOS 6, a user would need to replace postfix with some other MTA first and uninstall mysql-libs.
Oracle solves this by providing mysql-shared-compat rpm, with a collection of old client libraries. We could do the same...
Let's try to build MariaDB-compat by repackaging MariaDB-shared-5.3 rpm
Attachments
Activity
basically, building mariadb-compat works. At the moment cmake does not download 5.3 rpm, it expects it to be present. So it's up to the buildbot to put the mariabd-shared-5.3 rpm in the vm. we can change it to let cmake download it.
new rpms depend on each other. "rpm -ivh *rpm" does not honor them properly, test installations in the buildnbot fail.
I've changed buildbot to use "yum install *.rpm" instead. Presumably it's actually more correct - the recommended redhat package management tool is yum, so we should test with yum, not the low-level rpm. New problem - most of the install vms aren't ready for that. Need to discuss with dbart whether we should fix vms, or use rpm -ivh.
I brought up the CentOS 6 rpms conflict issues with Oracle on their MySQL-5.5 community rpms.
Fixing the dependency issues is really important as otherwise you break the base OS on which you are working. So it's clear that you have to do something similar which is to obsolete the mysql-libs rpms and provide an alternative which allows MariaDB-server/client to install cleanly, but at the same time provide existing functionality.
So will follow this with interest as while not using CentOS 6 on the MariaDB servers I'm using at the moment, that point may not be far off. (The issue caused by the MySQL-5.5 rpms caused a huge amount of pain.)
Simon, in my last comment I've mentioned that new 5.5 rpms cannot be tested automatically in buildbot.
But when I test them manually, installing like "yum install MariaDB*.rpm" works just fine on the base OS - removes mysql-libs, installs MariaDB, no conflicts.
We'll release them in a few days.
To better test yum installations, it would make sense to create a yum repository with the rpms. This is done by running:
createrepo ${dir}
...where ${dir} is the directory on the install-testing VM where the rpm and srpm directories are (the actual RPMs are in the rpm and srpm dirs). This will create a repodata directory with the appropriate metadata for yum. On the install-testing VMs, there needs to be a file placed under /etc/yum.repos.d/ which points to the location. In anticipation of wanting to eventually test YUM repo installs in buildbot, on the install VMs I created last week I placed a file which points at:
file:///home/buildbot/buildbot/rpms
So as long as the repodata and rpm/srpm dirs are in that directory on the install-testing VM, things should "just work". If that is not the correct directory, regenerating the install VMs is pretty simple, so the location can be easily changed.
from Mageia,
http://svnweb.mageia.org/packages/cauldron/mariadb/current/SPECS/mariadb.spec
revision 233779