Description of problem: TL;DR: packages in Fedora should use mariadb-connector-c instead of mariadb-libs for MySQL/MariaDB client side functions. For a longer story, read goo.gl/zHuQDU.
(^) Up are packages that either: builds fine needs a minor patch and a such is proposed or does not use mysql-devel at all (but have it as a Buildrequires) --- (v) Follows packages that most likely will need a patch, but they FTBFS for a long time
(v) Below comes packages that builds with errors for which a patch is not yet know at the time of bug creation.
That's all from me for now. All the way up there should be every single package (without one or two) that uses some mysql part from community-mysql or mariadb. Hope I didn't forget any.
This change also broke rawhide compose today (because the kde live, which is release blocking was trying to install mariadb-libs). I've sent a pr to fix that. However, it would have been nice to make this a f28 change and announce it so everyone knew what was going on here without having to dig. ;(
Why was this change implemented in this way? Last time the preferred mysql client library changed in Fedora it was implemented in a much more packager friendly way. What happened was that the "mysql-devel" provides was removed from the old preferred library and added to the new preferred library. I.e. this required a change in two packages, not in every single package that requires a mysql client library to build against. A better way to implement this would be to remove the "mysql-devel" provides from mariadb-devel, and add it to mariadb-connector-c-devel. This would greatly reduce the number of packages that needs changes, and the next time the preferred mysql client library implementation changes you can do the same thing again and not have to change all the source packages again.
There starts to be namespace pollution. 1) There was package 'mysql'. After some time it was dropped from Fedora, and 2) package 'community-mysql' appeared. 3) after longer time, 'mariadb' package appeared --- Because MariaDB was drop-in replacement for MySQL, both packages 'mariadb' and 'community-mysql' provided 'mysql'. When somebody wanted *some mysql*, they used "Requires: mysql", which usually pointed to 'mariadb' package. --- After some time, while getting latest stable upstream stuff, we went from mariadb 5.5 (which is true drop-in replacement for mysql 5.5) through mariadb 10.0 and 10.1 to mariadb 10.2. And at this point, the differencies between Fedora packages 'community-mysql' and 'mariadb' began to be huge - from the developement view. Still, almost all functionality is the same as mysql, but recently we had client library rewrite and rename, devel files changed their location and some does weird stuff (like double mysql.h problem), ... However the (other) packages are not prepared for such a changes. In many cases, they don't use mysql_config properly or don't use it al all! That mean, they are very fragile to any change; they won't apply new *.so libraries or paths to *.h libraries, even if the informations are served by "mysql_config" from /usr/bin. --- In the light of this, my ultimate goal is to remove provides of "mysql" from Fedora. Because packages (well, better developers), needs to know what they really want to use. In the meantime, the opportunity to pack 'mariadb-connector-odbc' 3.x appeared, but it required verison 3.x on 'mariadb-connector-c'. While I'm packing them, it could be handy to drop client library part from the server and use connector-c instead - as it is meant to. So I started to do so. In rawhide the 'mariadb-libs' is no more, and its functionality is replaced by 'mariadb-connector-c'. In addition the 'mariadb-devel' package now provides only server part for developement, while 'mariadb-connector-c-devel' provides everything for client side developement - which is everything, that more than 95% packages needs. More to say, the "Require: mariadb-libs" don't look valid to me. All the dependencies to the library should be generated automaticly by RPM. If it is not, something's wrong. Needless to say, 'mariadb-connector-c*' packages still needs to deal with things like library rename (and provides both mysql and mariadb library now). --- In order to keep thing easy and straightforward in the future, like: * MAINTAINER knows what he needs to require ('mariadb-connector-devel' instead of "mysql-devel") * MAINTAINER knows what he really gets ("mysql" expanding to 'mariadb' or 'community-mysql') * MAINTAINER doesn't require what he shouldn't (*.so libs whould be added by RPM) * USERS will have smaller DNF update (size of connector X size of mariadb) ( * and my head doesn't blow away by keeping track of all of that ... ) I made this bigger change in RAWHIDE and for almost everybody I added patches they need. All of that after weeks of testing in COPR and profiling mariadb and maridb-connector packages to the best shape and compatibility. (Actually I'm really sad I broke Kevins's compose, after all this preparation) --- ... I'm open for a discussion, but those things are complicated as hell. God bless I'm not doing them really alone. (f.e.: hey, hhorak, thanks for OpenSSL backport to MDB 10.1 lately !) FUN FACT as a bonus: ... you don't even know I want to do part of it in F27 too :D (well, there I can't break MariaDB, but packages that needs really only connector could be updated seemlessly)
If you encounter any issue with package updates, please see: https://bugzilla.redhat.com/show_bug.cgi?id=1497234#c7
I'm not against the mariadb-connector-c naming, but since RPM distros historically name client side like 'mysql.rpm' or 'mariadb.rpm', one really expects that 'mariadb-devel' means client devel package (when separated). So I wouldn't be against re-naming 'mariadb-devel' to 'mariadb-server-devel', and as Mattias proposes provide 'mysql-devel' and 'mariadb-devel' in 'mariadb-connector-c-devel' (unless there are any obvious issues I can't think of now). This brings one additional advantage -- so that if we, for some strange reasons, moved the client library back into mariadb package (for example in collections) we could re-provide the subpackage. Just saying.
Hi, Could we make it compatible with epel 7 ? please. I got this error when tried to build on epel 7 [1] [1] DEBUG util.py:439: Error: No Package found for mariadb-connector-c-devel
Another question how we replace " Requires: mariadb-server >= 5, mariadb >= 5 " to be compatible with community-mysql ? Thanks
(In reply to Sergio Monteiro Basto from comment #10) > Another question how we replace " Requires: mariadb-server >= 5, mariadb >= > 5 " to be compatible with community-mysql ? MariaDB 5.x is a drop-in replacement for mysql 5.x. So if you were using MariaDB 5.x, you should be able to switch to community-mysql 5.x without any problem. In that case, the requires should be simmilar: "Requires: community-mysql >= 5" "Requires: community-mysql-server >= 5" However I don´t se any point in specifying the version, since you surely won't encounter any older releases in fedora. I hope I answered your question. -- About the EPEL - I have no information about it (I'm not its maintainer), so I must do some research. However RH provides MariaDB in RHEL7, so the should be no need for such epel package. On the other hand latest versions (10.1, 10.2) AFAIK were only provided as a RHSCL (software collections). I'll check it, but I don't see any point of making any compatibility changes agains RHEL7. Fedora is an OS with fast developement cycle aiming at bringing the latest tech advancements into it.
(In reply to Michal Schorm from comment #11) > (In reply to Sergio Monteiro Basto from comment #10) > > Another question how we replace " Requires: mariadb-server >= 5, mariadb >= > > 5 " to be compatible with community-mysql ? > > MariaDB 5.x is a drop-in replacement for mysql 5.x. > > So if you were using MariaDB 5.x, you should be able to switch to > community-mysql 5.x without any problem. > > In that case, the requires should be simmilar: > "Requires: community-mysql >= 5" > "Requires: community-mysql-server >= 5" > > However I don´t se any point in specifying the version, since you surely > won't encounter any older releases in fedora. > > I hope I answered your question. No, the question is about how require one of the two options (mysql or mariadb) By example [1] I can't install mythtv because requires mariadb and I have installed mysql, when mythtv should be agnostic about it ! and I'd like fix mythtv package , if it is possible . So, have I any option to replace "Requires: mariadb " ? , please forget the "> 5" Many Thanks, [1] https://pkgs.rpmfusion.org/cgit/free/mythtv.git/tree/mythtv.spec#n353 > -- > > About the EPEL - I have no information about it (I'm not its maintainer), so > I must do some research. > However RH provides MariaDB in RHEL7, so the should be no need for such epel > package. On the other hand latest versions (10.1, 10.2) AFAIK were only > provided as a RHSCL (software collections). > > I'll check it, but I don't see any point of making any compatibility changes > agains RHEL7. Fedora is an OS with fast developement cycle aiming at > bringing the latest tech advancements into it.
Hello , In resume, please, how I solve [1] ? [1] Requires: mariadb-server mariadb or Requires: community-mysql-server community-mysql Sorry for my weak English .
Hi, The question is more likely invalid at all. However I'll frist answer what you are asking exactly: No, there is no way to (Require: 1 OR Require: 2) -- But you shouldn't hit this in the first place. As the MariaDB and MySQL libraries slowly start to differ, it is importatnt to decide, if you want to build against one or another. If you build against mariadb-connector-c, you should use MariaDB. Else if you build against community-mysql-devel, you should use community-mysql. The software built will be likely not functional with the opposite library. -- More, if you build package against mariadb-connector-c (for example), and you use RPM for building it, it will automatically generate "Requires" for all the dynamic libraries needed. In the case, if your software only need the library (and not running server with client, for example) you don't need to add any more Requires by hand. That also means, RPM will know, which library to choose afterwards. -- If you want to build against both, I'd suggest conditional macros in the SPECfile.
(In reply to Michal Schorm from comment #14) Hi first many thanks for your help, I found out and hopefully both (mysql and mariadb) packages provides mysql-compat-server and mysql so I solved my question with: Requires: mysql-compat-server mysql Many thanks for your time and best regards
There still seems to be a clean upgrade problem even with migrated packages (at least via dnf system-upgrade). For example: * Install a fresh F27 Workstation live ISO VM * sudo dnf --refresh upgrade -y * sudo dnf install opencv-core # pulls in mariadb-libs via gdal-libs * sudo dnf install dnf-plugin-system-upgrade * sudo dnf --refresh system-upgrade --releasever 28 download -y Result: $ sudo dnf --refresh system-upgrade --releasever 28 download -y Last metadata expiration check: 0:00:00 ago on Wed 04 Apr 2018 15:36:02 BST. Error: Problem: package mariadb-libs-3:10.2.14-1.fc27.x86_64 requires mariadb-common(x86-64) = 3:10.2.14-1.fc27, but none of the providers can be installed - mariadb-common-3:10.2.14-1.fc27.x86_64 does not belong to a distupgrade repository - problem with installed package mariadb-libs-3:10.2.14-1.fc27.x86_64 However, the following works fine: * Install a fresh F28 Workstation live ISO VM * sudo dnf --refresh upgrade -y * sudo dnf install opencv-core # pulls in mariadb-connector-c via gdal-libs I'm not sure why it is that given the success of the latter, dnf system-upgrade can't figure out the upgrade path, but this is a significant upgrade issue given that plenty of stuff depends/depended on mariadb-libs. Perhaps the F27 package dependencies need to be migrated to mariadb-connector-c as well?
p.s. Honza please don't use URL shorteners, they turn the original URL into a blind link, and Google already hoovers up enough data about everyone already ;) goo.gl/zHuQDU -> https://fedoraproject.org/wiki/User:Hhorak/mariadb-connector-c-proposal
Looks like this is fixed in updates-testing, nvm.
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.