Page 1 of 1

Improve backports repos

PostPosted: Jun 1st, '25, 12:03
by irondave
Hello folks,
from time to time I take the liberty of suggesting the use of Mageia to those who request assistance on various social networks regarding which distro to use.
Unfortunately, it often happens that users don't know Mageia at all and some are amazed that the distro is still alive.
Investigating a little why people think that Mageia is no longer in development turns out that the cause is the dated software.
Obviously I happen to chat with people who appreciate stability even if this is to the detriment of software updates, but these are still the minority.
The most popular distros today, and which are therefore advertised and recommended the most, are Fedora, openSUSE Tumbleweed (or Slowroll) and Archlinux.
These three distributions have in common that they release a software update with little time gap from the official release.

Sorry for the long introduction but I think it helps to understand why Mageia users are not increasing.

Thinking about how to mitigate the situation I thought that the use of repo backports could be the solution.
I have already proposed this idea in another post but I would like to create a more open discussion on the topic.

Quoting "QA process for validating backports" page on the wiki:
"Our policy is not to update to newer versions of packages in stable Mageia releases where possible but to apply patches for bugs and security vunerabilities. This helps to increase the stability of the distribution. For example you should not run into problems of incompatibility by updating a package. A new version may add or drop support for various things which could be disastrous if you were relying on that support for something important.

A backport is a new version of a package which is available in Cauldron, the development branch, and is being made available in our stable releases in special backport medias. These medias are not enabled by default and are not intended to be used as regular update medias.

For instance:

If there is a package called xmoto. There may be xmoto version 3.2 available in normal release or update medias. The functionality of xmoto 3.2 will not have changed between the time this particular Mageia was released and the time now.

Cauldron often has the latest versions, it is where the next Mageia release is being built, but it is not stable and can/will break. That is to be expected.

It may be that xmoto version 4 is available now in Cauldron, so the maintainer of xmoto has decided to also make it available in the stable Mageia releases as it adds some fancy function which isn't currently available. They can do that by providing a backport of xmoto 4 into the stable releases using the backport medias."


We all agree that upgrades will (almost) never fail but backports can be cherry-picked (enable backports, install/upgrade, disable backports).

Therefore my suggestion would be to populate the repo backports automatically when a package is updated on Cauldron.

To be clear:
- Mageia 9 (current stable release) has version 1.0 of the package XYZ;
- when the XYZ package is updated to a minor version (point release, ie 1.1, 1.2, 1.3, etc.), it will be updated in Mageia Cauldron and then to the stable release through the "updates" repositories (core-updates, nonfree-updates, and tainted-updates);
- when the XYZ package is updated to a major version (version 2), it is first added to the Cauldron repository for initial QA testing and when the XYZ package is updated to a new minor version (i.e. 2.1, 2.2, 2.3, etc.), it will be updated in Cauldron (from the version 2.0), and the previous version will be automatically moved to the "backports" repos (core-backports, nonfree-backports, and tainted-backports).

I don't know if I made my idea clear.
What do you think?

Re: Improve backports repos

PostPosted: Jun 1st, '25, 16:21
by doktor5000
I can comprehend the suggestions, you explained it pretty well. Although it's sadly not that easy, speaking as a former packager.
Everything that goes through the update repositories has to be tested by the QA team, they test if normal functionality is still there, and usually also if security vulnerabilities are actually fixed (if a proof of concept for a vulnerability exists) for security updates.
So it's not that easy to simply push every minor version update from cauldron to the newest stable distro version.

Also for backports you have to consider that this cannot be easily automated. Mostly there's a timegap of 1 year for the base libraries of the stable distro version against cauldron.
Often current releases of newer software also require current versions of multiple dependencies (mostly libraries but also part of the buildsystem e.g. autoconf/automake/cmake etc.) and those dependencies often require newer versions of other libraries.
So it's really not that simple as submitting the cauldron version to the newest stable distro versions backports repositories, it often requires manual adjustment to the older stable distro and you need to manually submit all required dependencies.

And currently there aren't even enough packagers around to fully maintain all packages for cauldron AND the newest stable distro version, let alone for some additional backports.

I don't get that push about newer versions anymore nowadays - when I started with Mandrake/Mandriva I was also infected by this "version illness" and wanted newer versions here and there.
But nowadays I mostly value that something works, and when you require something recent you can often get it as flatpak/appimage or directly from the upstream project without much or any effort.
And for packages that require actual version updates (e.g. something like yt-dlp or other software that needs to be recent as it connects to some online services) those are exempt from our updates policy and are also provided for the stable distro version.

Re: Improve backports repos

PostPosted: Jun 1st, '25, 18:38
by morgano
As doctor already mention, Flatpak is one of option to get frequent updates of some popular applications, or applications not packaged in Mageia.
Other methods see: https://wiki.mageia.org/en/Ways_to_install_programs