Bug 1486480 - [Tracker] Packages that require the MySQL/MariaDB client library should use mariadb-connector-c
Summary: [Tracker] Packages that require the MySQL/MariaDB client library should use m...
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: mariadb-connector-c
Version: 27
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Michal Schorm
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1494074 1494229 1488483 1493612 1493615 1493616 1493618 1493620 1493621 1493624 1493625 1493626 1493627 1493628 1493629 1493630 1493631 1493632 1493633 1493634 1493635 1493653 1493654 1493655 1493657 1493658 1493659 1493660 1493661 1493662 1493663 1493682 1493683 1493684 1493685 1493686 1493687 1493688 1493689 1493690 1493691 1493692 1493693 1493694 1493695 1493696 1493697 1493698 1493699 1493904 1493906 1493907 1493908 1493909 1493912 1494049 1494051 1494054 1494068 1494070 1494071 1494072 1494075 1494076 1494077 1494079 1494080 1494081 1494083 1494084 1494085 1494091 1494093 1494094 1494095 1494096 1494097 1494098 1494099 1494100 1494104 1494105 1494106 1494221 1494225 1494227 1494241 1494303 1494304 1494307 1501933
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-08-29 21:46 UTC by Honza Horak
Modified: 2018-11-30 20:48 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-11-30 20:48:30 UTC


Attachments (Terms of Use)

Description Honza Horak 2017-08-29 21:46:06 UTC
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.

Comment 1 Michal Schorm 2017-09-21 12:25:15 UTC
(^) 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

Comment 2 Michal Schorm 2017-09-21 12:47:52 UTC
(v) Below comes packages that builds with errors for which a patch is not yet know at the time of bug creation.

Comment 3 Michal Schorm 2017-09-21 13:03:21 UTC
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.

Comment 4 Kevin Fenzi 2017-09-21 16:12:14 UTC
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. ;(

Comment 5 Mattias Ellert 2017-09-25 14:14:44 UTC
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.

Comment 6 Michal Schorm 2017-09-26 12:31:01 UTC
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@redhat.com, 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)

Comment 7 Michal Schorm 2017-10-04 11:20:41 UTC
If you encounter any issue with package updates, please see:
  https://bugzilla.redhat.com/show_bug.cgi?id=1497234#c7

Comment 8 Pavel Raiskup 2017-10-13 15:49:04 UTC
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.

Comment 9 Sergio Monteiro Basto 2017-12-23 19:47:40 UTC
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

Comment 10 Sergio Monteiro Basto 2018-01-10 01:54:38 UTC
Another question how we replace " Requires:  mariadb-server >= 5, mariadb >= 5 " 
to be compatible with community-mysql  ? 

Thanks

Comment 11 Michal Schorm 2018-01-11 15:55:08 UTC
(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.

Comment 12 Sergio Monteiro Basto 2018-01-11 16:31:29 UTC
(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.

Comment 13 Sergio Monteiro Basto 2018-01-15 13:19:42 UTC
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 .

Comment 14 Michal Schorm 2018-01-16 11:55:48 UTC
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.

Comment 15 Sergio Monteiro Basto 2018-01-28 04:48:10 UTC
(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

Comment 16 fednuc 2018-04-04 14:41:24 UTC
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?

Comment 17 fednuc 2018-04-04 14:46:55 UTC
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

Comment 18 fednuc 2018-04-04 18:42:23 UTC
Looks like this is fixed in updates-testing, nvm.

Comment 19 Ben Cotton 2018-11-27 16:20:07 UTC
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.

Comment 20 Ben Cotton 2018-11-30 20:48:30 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.