On Mon, Oct 23, 2023 at 5:23 AM Michal Schorm <mschorm@xxxxxxxxxx> wrote: > > 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. > > For what it's worth, I have increasingly encountered issues with the interchangeability of the two. In a previous job, there was a lot of drive toward MariaDB initially, but then they switched to MySQL (particularly with Galera or XtraDB). In the end, they have become increasingly divergent implementations with a common ancestor. And that's fine. > > > 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. > > We have a few examples of this for libraries and runtimes, I don't think it'd be too difficult to do for database software too. The advantage of this is that it maintains the principle of least surprise, and people will be upgraded by default to the latest versions in a way they expect. I'd like to see this for PostgreSQL someday too... > > > 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. > I'd prefer it in mainline Fedora too, so I appreciate your efforts here. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
