On Monday 20 June 2011 22:40:48 Dennis Jacobfeuerborn wrote:
On 06/20/2011 08:31 PM, Kevin Fenzi wrote:
On Mon, 20 Jun 2011 21:11:17 +0300
Marian Marinovmm@yuhu.biz wrote:
I have thought about building both MySQL packages as a separate daemons but the problem is that since they are one and the same, they use the same port ,the same configuration files and the same data directories.
Althou that could be changed with a few simple patches this would make them somewhat cripled. Also the userland tools use the same configuration files (~/.my.cnf) which will complicate things even more.
Is it possible for the EPEL policy to bend a little here for at least one of these packages ?
I suppose these could fall under the compatibility packages thing we have been talking about for things like newer boost or the like.
http://fedoraproject.org/wiki/Packaging:Conflicts#Compat_Package_Conflict s
I think we are drving down a slippery slope here tho. A downside of this kind of thing also is packages or people who do 'yum install /usr/bin/mysqld'. They aren't really sure what they will get there.
I agree here, when the exceptions become too many then they start to overrule the policy.
That doesn't look like much of a problem though. If you need something specific then you should install something specific. If on the other hand "anything that provides /usr/bin/mysqld" is good enough then you can't really complain.
I wonder if this wouldn't be better in IUS?
Or talk with upstream about renaming things so it can parallel install, and then perhaps we could change packages to need 'mysql-database' or something that could get added as a virtual provides to all of these?
The question is if the other upstreams consider themselves to be alternative implementations of MySQL and pledge to uphold compatibility or if they consider themselves to be forks of the original project. If it's the latter then they should live in their own space and change names of binaries, paths, etc. the same way drizzle did. If they are simply alternative implementations though this would probably have to be resolved using proper conflicts/provides in the rpm's.
For MariaDB I'll talk with the developers since at some point in time(soon) they will be completely different then MySQL(they already did a few renameings). And this may make them uncompatible with MySQL.
For Percona however, this is not the case. They use the sources provided by Oracle and simply add the Google patches and their own engine patches. They don't change anything else, which makes them a drop in replacement for MySQL with a future plans to stay that way.
Regards, Marian
Regards, Dennis