Hello, I'm planning on proposing both Percona-SQL and MariaDB packages for inclusion in the EPEL-5 repo.
I wish to know would you accept these packages in EPEL if they are a replacement of the current mysql.
I already talked with Peter Zaitsev from Percona and he agreed. He also told me that they will support my efforts of including Percona-SQL into EPEL. I also wrote to MariaDB developers mailing list to inform them about my intentions.
And also I need to know what would be the best way to replace the mysql packages?
Which would be better Conflicts or Obsoletes when replacing the current mysql ? I think that Obsoletes is the way to go here, since once you upgrade to either Percona or MariaDB you would want to coninue upgrade that package, but please give me some comments.
Best regards, Marian Marinov
On 06/19/2011 07:01 PM, Marian Marinov wrote:
I'm planning on proposing both Percona-SQL and MariaDB packages for inclusion in the EPEL-5 repo.
I wish to know would you accept these packages in EPEL if they are a replacement of the current mysql.
I think that's clearly a "no".
http://fedoraproject.org/wiki/EPEL#What_is_Extra_Packages_for_Enterprise_Lin...
"EPEL packages [...] will never conflict with or replace packages in the base Enterprise Linux distributions."
On Sunday 19 June 2011 20:45:17 Ville Skyttä wrote:
On 06/19/2011 07:01 PM, Marian Marinov wrote:
I'm planning on proposing both Percona-SQL and MariaDB packages for inclusion in the EPEL-5 repo.
I wish to know would you accept these packages in EPEL if they are a replacement of the current mysql.
I think that's clearly a "no".
http://fedoraproject.org/wiki/EPEL#What_is_Extra_Packages_for_Enterprise_Li nux_.28or_EPEL.29.3F
"EPEL packages [...] will never conflict with or replace packages in the base Enterprise Linux distributions."
Huh, I'm sorry I forgot that. I'll talk with the CentOS guys to see if I can include them in the CentOSplus repo.
Regards, Marian
Depending on the definition of replace I wonder if you could do a Provides: mysql as long as your the packages would appear similarly to dependent packages.
Sent from my iPhone
On Jun 19, 2011, at 2:19 PM, Marian Marinov mm@yuhu.biz wrote:
On Sunday 19 June 2011 20:45:17 Ville Skyttä wrote:
On 06/19/2011 07:01 PM, Marian Marinov wrote:
I'm planning on proposing both Percona-SQL and MariaDB packages for inclusion in the EPEL-5 repo.
I wish to know would you accept these packages in EPEL if they are a replacement of the current mysql.
I think that's clearly a "no".
http://fedoraproject.org/wiki/EPEL#What_is_Extra_Packages_for_Enterprise_Li nux_.28or_EPEL.29.3F
"EPEL packages [...] will never conflict with or replace packages in the base Enterprise Linux distributions."
Huh, I'm sorry I forgot that. I'll talk with the CentOS guys to see if I can include them in the CentOSplus repo.
Regards, Marian _______________________________________________ epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
On Sun, Jun 19, 2011 at 8:53 PM, Aaron Knister aaron.knister@gmail.com wrote:
Depending on the definition of replace I wonder if you could do a Provides: mysql as long as your the packages would appear similarly to dependent packages.
Ignoring EPEL for now if there are multiple mysqls arround then encouraging Fedora to adapt the mysql to support alternatives has to be the long term solution.
Note I have never ever looked at MariaDB or Percona. Do they really use the same deamon names, library names, etc,....?
Is MySQL to Percona MySQL to MariaDB the same as sendmail to exim to postgres?
Steve
On Sunday 19 June 2011 22:17:11 Steve Traylen wrote:
On Sun, Jun 19, 2011 at 8:53 PM, Aaron Knister aaron.knister@gmail.com
wrote:
Depending on the definition of replace I wonder if you could do a Provides: mysql as long as your the packages would appear similarly to dependent packages.
Ignoring EPEL for now if there are multiple mysqls arround then encouraging Fedora to adapt the mysql to support alternatives has to be the long term solution.
Note I have never ever looked at MariaDB or Percona. Do they really use the same deamon names, library names, etc,....?
Is MySQL to Percona MySQL to MariaDB the same as sendmail to exim to postgres?
They are actually the same code. Percona is Oracle's MySQL but includes the google patches(InnoDB high performance and user statistics). Percona also adds one more storage engine XtraDB.
MariaDB was a fork of MySQL when it began. Now it has a lot of changes that make it quite different, again adding some of the Google patches and adding new storage engines.
So all 3 packages generate the same binaries and libraries. So in fact they are the same thing. Both MariaDB and Percona-SQL are drop in replacements of Oracle's MySQL.
This is why I think of them as a replacement of the default MySQL. MySQL stopped accepting patches changing the general functionality of MySQL when they were aquired by SUN. So then was born Percona, it was needed because a lot of us want the Google patches. And when Oracle aquired SUN, MariaDB fork was born.
Steve
On Sunday 19 June 2011 22:38:28 Marian Marinov wrote:
On Sunday 19 June 2011 22:17:11 Steve Traylen wrote:
On Sun, Jun 19, 2011 at 8:53 PM, Aaron Knister aaron.knister@gmail.com
wrote:
Depending on the definition of replace I wonder if you could do a Provides: mysql as long as your the packages would appear similarly to dependent packages.
Ignoring EPEL for now if there are multiple mysqls arround then encouraging Fedora to adapt the mysql to support alternatives has to be the long term solution.
Note I have never ever looked at MariaDB or Percona. Do they really use the same deamon names, library names, etc,....?
Is MySQL to Percona MySQL to MariaDB the same as sendmail to exim to postgres?
They are actually the same code. Percona is Oracle's MySQL but includes the google patches(InnoDB high performance and user statistics). Percona also adds one more storage engine XtraDB.
MariaDB was a fork of MySQL when it began. Now it has a lot of changes that make it quite different, again adding some of the Google patches and adding new storage engines.
So all 3 packages generate the same binaries and libraries. So in fact they are the same thing. Both MariaDB and Percona-SQL are drop in replacements of Oracle's MySQL.
This is why I think of them as a replacement of the default MySQL. MySQL stopped accepting patches changing the general functionality of MySQL when they were aquired by SUN. So then was born Percona, it was needed because a lot of us want the Google patches. And when Oracle aquired SUN, MariaDB fork was born.
Steve
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 ?
Best regards, Marian
On Mon, 20 Jun 2011 21:11:17 +0300 Marian Marinov mm@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_Conflicts
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 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?
Not sure there's a good answer here.
kevin
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_Conflicts
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.
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.
Regards, Dennis
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
On Tuesday 21 June 2011 00:43:30 Marian Marinov wrote:
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_Confli ct 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.
Ok this statement is wrong. I have just been convinced by the MariaDB devs, that MariaDB will remain 100% compatible with the file formats of Oracle's MySQL which automatily joins it with Percona. It is in the same situation. MariaDB roadmap will introduce new storage engines and better query optimizer, but everything that is myisam and innodb will be 100% compatible.
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
On Sunday 19 June 2011 21:53:46 Aaron Knister wrote:
Depending on the definition of replace I wonder if you could do a Provides: mysql as long as your the packages would appear similarly to dependent packages.
Yes, I think it should do 'Provides: mysql'. Otherwise it will break quire a few packages.
But as far as I understand, this is again a replacement of a base package.
Sent from my iPhone
On Jun 19, 2011, at 2:19 PM, Marian Marinov mm@yuhu.biz wrote:
On Sunday 19 June 2011 20:45:17 Ville Skyttä wrote:
On 06/19/2011 07:01 PM, Marian Marinov wrote:
I'm planning on proposing both Percona-SQL and MariaDB packages for inclusion in the EPEL-5 repo.
I wish to know would you accept these packages in EPEL if they are a replacement of the current mysql.
I think that's clearly a "no".
http://fedoraproject.org/wiki/EPEL#What_is_Extra_Packages_for_Enterprise _Li nux_.28or_EPEL.29.3F
"EPEL packages [...] will never conflict with or replace packages in the base Enterprise Linux distributions."
Huh, I'm sorry I forgot that. I'll talk with the CentOS guys to see if I can include them in the CentOSplus repo.
Regards, Marian _______________________________________________ epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
On 06/19/2011 09:40 PM, Marian Marinov wrote:
On Sunday 19 June 2011 21:53:46 Aaron Knister wrote:
Depending on the definition of replace I wonder if you could do a Provides: mysql as long as your the packages would appear similarly to dependent packages.
Yes, I think it should do 'Provides: mysql'. Otherwise it will break quire a few packages.
But as far as I understand, this is again a replacement of a base package.
If you package them as a direct replacement for mysql then yes but I would argue given that these versions are changed quite a bit they sould be packaged separately instead.
Regards, Dennis
Is it possible to add a small discussion about Percona and MariaDB to the schedule of the next monday IRC meeting ?
Marian
On Thu, 23 Jun 2011 12:32:28 +0300 Marian Marinov mm@yuhu.biz wrote:
Is it possible to add a small discussion about Percona and MariaDB to the schedule of the next monday IRC meeting ?
Sure. :)
Will you be able to attend?
Just add it at:
https://fedoraproject.org/wiki/EPEL_SIG
(at the bottom in agenda items)
kevin
On Thursday 23 June 2011 15:59:35 Kevin Fenzi wrote:
On Thu, 23 Jun 2011 12:32:28 +0300
Marian Marinov mm@yuhu.biz wrote:
Is it possible to add a small discussion about Percona and MariaDB to the schedule of the next monday IRC meeting ?
Sure. :)
Will you be able to attend?
Just add it at:
https://fedoraproject.org/wiki/EPEL_SIG
(at the bottom in agenda items)
Thank you, I added it. I will be there, I stay in the #epel channel nick HackMan.
kevin
epel-devel@lists.fedoraproject.org
-
Aaron Knister -
Dennis Jacobfeuerborn -
Kevin Fenzi -
Marian Marinov -
Steve Traylen -
Ville Skyttä