Self introduction, and maintaining MySQL package

Honza Horak hhorak at
Thu May 2 15:53:46 UTC 2013

On 05/02/2013 09:07 AM, Bjorn Munch wrote:> On 01/05 11.58, Michael 
Schwendt wrote:
 >> On Tue, 30 Apr 2013 15:08:08 +0200, Bjorn Munch wrote:
 >>> Since I do not yet have a sponsor, I cannot upload to
 >> That is misinformation. Note the bottom of the following paragraph:
 > I have registered on and added my ssh key but I
 > could not upload. I'm not quite sure what I needed to do and in which
 > order. It doesn't quite follow the normal pattern since I'm not adding
 > a *new* package, just offering to keep maintaining an existing one.

I'm really glad to see some real action from your part finally. Just 
generally, package renaming is more or less "new package process" + 
"retiring process" together, so you can safely follow new package 

 > I have just submitted a request for rename of the package
 > community-mysql "back" to mysql-community:

However, I need to repeat that this could have some impact to choosing 
default package when asking for "mysql" name, as I've described at:

I admit that the example there is not very common case, but since there 
*is* at least one existing, I'd rather stick with less nice, but more 
safe name community-mysql. How can you ensure that there is not any 
other (potentially more common) use case where something similar can 
happen? Testing several common use cases where mysql-community works is 
not an argument for me, since yum is too complex for this.

One recent example -- I've found that perl-DBD-MySQL got build against 
community-mysql few weeks back, when the current builds of 
community-mysql and mariadb were already in the repo. Honestly, I don't 
have a clue how that could happen, but it was another proof for me, that 
we should take the safest way as we could. Fortunately, in this case 
removing mysql-devel and mysql-embedded-devel providers from 
community-mysql packages should work fine.


More information about the devel mailing list