i understand the release-it-from-distro argument, but my $0.02,
MDB @ Fedora has version-lagged for so long, with no response to requests to
update, either official distro, or modules, that I switched to upstream.
https://mariadb.com/kb/en/mariadb-package-repository-setup-and-usage/
https://mariadb.com/kb/en/yum/#installing-mariadb-packages-with-yum
with,
cat mariadb.repo
[mariadb]
enabled=1
name = MariaDB
baseurl =
https://ftp.osuosl.org/pub/mariadb/yum/10.11/fedora/$releasever/$basearch
gpgkey=https://ftp.osuosl.org/pub/mariadb/yum/RPM-GPG-KEY-MariaDB
gpgcheck=1
sure, it has its occasional problems. but it gets timely support from upstream devs, and a very large active community
rpm -qa | grep -i maria | sort
MariaDB-backup-10.11.5-1.fc38.x86_64
MariaDB-client-10.11.5-1.fc38.x86_64
MariaDB-common-10.11.5-1.fc38.x86_64
MariaDB-cracklib-password-check-10.11.5-1.fc38.x86_64
MariaDB-gssapi-server-10.11.5-1.fc38.x86_64
mariadb-java-client-3.1.2-1.fc38.noarch
MariaDB-server-10.11.5-1.fc38.x86_64
MariaDB-shared-10.11.5-1.fc38.x86_64
perl-DBD-MariaDB-1.22-4.fc38.x86_64
-------- Original Message --------
From: devel@lists.fedoraproject.org
Sent: at Thursday, Oct 19, 2023, 19:11 PM EDT
To: devel@lists.fedoraproject.org Cc: kevin.kof...@chello.at
Subject: Re: F40 Change Proposal: F40 MariaDB MySQL repackaging (Self-Contained)
* 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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
