Hi, On Fri, Oct 20, 2023 at 1:12 AM Kevin Kofler via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > * Rename package 'community-mysql' to 'mysql' and Stop providing > > 'mysql' symbols by package 'mariadb' > > Why not just drop community-mysql (and keep mariadb as the provider of > mysql*) instead? I really do not see why we need to ship 2 competing forks > of the same database in Fedora. Applications typically do not even notice > the difference. > > > When MariaDB was introduced to Fedora, it seemed like it eventually > > replaces MySQL > > Is that not what has happened? Who still uses the Oracle crippleware? > > As I understand it, most distros are shipping only MariaDB. MySQL is definitely still on the scene. Few examples from the big distros here: Ubuntu: https://packages.ubuntu.com/search?suite=default§ion=all&arch=any&keywords=mysql&searchon=names Arch: https://aur.archlinux.org/packages/mysql Some distros dropped MySQL entirely, some favors MariaDB. None of that changes the fact that MySQL still is a popular DB. Take a look how many people use, or want to learn MySQL: https://survey.stackoverflow.co/2023/#most-popular-technologies-database https://survey.stackoverflow.co/2022/#most-popular-technologies-database What I want to do in Fedora is to merely recognize that MariaDB and MySQL are not fully interchangeable (drop-in) anymore. Their abilities and feature set grow diverse, so they both should have their own designated place, without pretending or confusion on which is which. > > I want to change the packaging structure so the result will look as > > follows: * The unversioned name ('mariadb') will become a meta-package > > ** It will point to the one versioned variant which I choose to be the > > default one for the given Fedora release > > ** It will provide all of the unversioned names for the versioned > > variant that is default for the given Fedora release, to minimize the > > changes visible to the users > > * All other versions will have their own versioned package (e.g > > "mariadb10.5" "mariadb10.11") and will conflict with each other > > > > This will allow for: > > * users to keep using the unversioned names they are used to > > * maintainer to change the default version for a given Fedora release > > on a single, centralized place > > * users to enjoy all of the features of the modularity I offered them, > > in a simpler way > > * maintainer to add new versions quickly, without any need of changing > > the default version (other than adding new conflicts) > > There is a major issue with this approach: Users installing Fedora 40 will > get the mariadb metapackages dragging in mariadb10.11. Then they upgrade to > Fedora 41 or 42 or whatever that will ship mariadb10.whatever. So then > mariadb will want to drag in mariadb10.whatever, but mariadb10.11 will also > want to get upgraded, leading to a conflict that DNF will not be able to > resolve in a satisfactory way. (Most likely, it will upgrade mariadb10.11, > keep the old Fedora n-1 version of the mariadb metapackage, and never > install the new mariadb10.whatever.) > > The default version should just be unversioned, instead of having the > unversioned package be a metapackage. Thanks for pointing that out, I'll look into it. > > Note: > > I specifically don't want the packages to be parallel installable. I > > only want them to be parallel available. > > That makes it a lot less useful to use versioned package names. > > I suggest you ship one set of MariaDB packages in Fedora, and then use Copr > to distribute different versions (which would also be named mariadb, not > e.g. mariadb10.5 or mariadb10.11, and just have, say, Version: 10.5 and, > since that is a downgrade compared to the official packages, Epoch: n+1, > where n is the Epoch of the official packages). To switch to a non-default > version, one would just dnf copr enable @mariadb-sig/mariadb-10.5 && dnf > upgrade (or distro-sync, but since it would be an "upgrade" at RPM level, > distro-sync is not needed here), and to switch back to the default version, > dnf copr disable @mariadb-sig/mariadb-10.5 && dnf distro-sync (to > "downgrade" to the official packages' lower EVR). I would like to have the alternative versions "closer" to Fedora. COPR is somehow "far", requiring users to be educated to know where to look and what to search for. I hope the parallel availability will significantly enhance the user experience, over any kind of "distant" repos. -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Fri, Oct 20, 2023 at 1:12 AM Kevin Kofler via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > * Rename package 'community-mysql' to 'mysql' and Stop providing > > 'mysql' symbols by package 'mariadb' > > Why not just drop community-mysql (and keep mariadb as the provider of > mysql*) instead? I really do not see why we need to ship 2 competing forks > of the same database in Fedora. Applications typically do not even notice > the difference. > > > When MariaDB was introduced to Fedora, it seemed like it eventually > > replaces MySQL > > Is that not what has happened? Who still uses the Oracle crippleware? > > As I understand it, most distros are shipping only MariaDB. > > > In Fedora, it is currently possible, on the packaging level, to cross > > install server of one DB with client of another. > > Specifically, you can install MariaDB server with MySQL client or > > MySQL server with MariaDB client. > > If you insist on shipping both implementations, I am not sure what can be > gained from disallowing this combination. But the easiest solution would of > course be to just drop the Oracle MySQL client and server altogether, then > by definition there is only one remaining combination (MariaDB client and > server). > > > Sadly, the drawbacks out-weights the positives. This behavior became a > > generator of elusive bugs I was never able to resolve. > > E.g.: https://bugzilla.redhat.com/show_bug.cgi?id=2026933 > > This is really a conflict between the MariaDB and Oracle MySQL packages, not > an issue with mixed ("cross") installations, and the only way to completely > get rid of such issues is to drop Oracle MySQL. > > > I want to change the packaging structure so the result will look as > > follows: * The unversioned name ('mariadb') will become a meta-package > > ** It will point to the one versioned variant which I choose to be the > > default one for the given Fedora release > > ** It will provide all of the unversioned names for the versioned > > variant that is default for the given Fedora release, to minimize the > > changes visible to the users > > * All other versions will have their own versioned package (e.g > > "mariadb10.5" "mariadb10.11") and will conflict with each other > > > > This will allow for: > > * users to keep using the unversioned names they are used to > > * maintainer to change the default version for a given Fedora release > > on a single, centralized place > > * users to enjoy all of the features of the modularity I offered them, > > in a simpler way > > * maintainer to add new versions quickly, without any need of changing > > the default version (other than adding new conflicts) > > There is a major issue with this approach: Users installing Fedora 40 will > get the mariadb metapackages dragging in mariadb10.11. Then they upgrade to > Fedora 41 or 42 or whatever that will ship mariadb10.whatever. So then > mariadb will want to drag in mariadb10.whatever, but mariadb10.11 will also > want to get upgraded, leading to a conflict that DNF will not be able to > resolve in a satisfactory way. (Most likely, it will upgrade mariadb10.11, > keep the old Fedora n-1 version of the mariadb metapackage, and never > install the new mariadb10.whatever.) > > The default version should just be unversioned, instead of having the > unversioned package be a metapackage. > > > Note: > > I specifically don't want the packages to be parallel installable. I > > only want them to be parallel available. > > That makes it a lot less useful to use versioned package names. > > I suggest you ship one set of MariaDB packages in Fedora, and then use Copr > to distribute different versions (which would also be named mariadb, not > e.g. mariadb10.5 or mariadb10.11, and just have, say, Version: 10.5 and, > since that is a downgrade compared to the official packages, Epoch: n+1, > where n is the Epoch of the official packages). To switch to a non-default > version, one would just dnf copr enable @mariadb-sig/mariadb-10.5 && dnf > upgrade (or distro-sync, but since it would be an "upgrade" at RPM level, > distro-sync is not needed here), and to switch back to the default version, > dnf copr disable @mariadb-sig/mariadb-10.5 && dnf distro-sync (to > "downgrade" to the official packages' lower EVR). > > Kevin Kofler > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
