> * 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
