Improve backports repos

This forum is dedicated to new ideas, suggestions and proposals.

Improve backports repos

Postby irondave » Jun 1st, '25, 12:03

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?
irondave
 
Posts: 9
Joined: Mar 19th, '19, 20:35

Re: Improve backports repos

Postby doktor5000 » Jun 1st, '25, 16:21

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.
Cauldron is not for the faint of heart!
Caution: Hot, bubbling magic inside. May explode or cook your kittens!
----
Disclaimer: Beware of allergic reactions in answer to unconstructive complaint-type posts
User avatar
doktor5000
 
Posts: 18042
Joined: Jun 4th, '11, 10:10
Location: Leipzig, Germany

Re: Improve backports repos

Postby morgano » Jun 1st, '25, 18:38

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
At home & work Mandriva since 2006, Mageia 2011. Thinkpad T40, T43, T60, T400, T510, Dell M4400, M6300, Acer Aspire 7. Workstation using LVM, LUKS, VirtualBox, BOINC
morgano
 
Posts: 1489
Joined: Jun 15th, '11, 17:51
Location: Kivik, Sweden

Re: Improve backports repos

Postby irondave » Jun 6th, '25, 12:17

doktor5000 wrote: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.


Understood, there isn't any way to automate the QA process?
For example both fedora and opensuse use openQA, can we do the same?

doktor5000 wrote: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.


What if I port to backports repo all of the required packages?

doktor5000 wrote: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.


That's unfortunate, but to have more people contributing to the project we first need to increase the user base.
To do that in my opinion you need to give users what they are looking for (updated packages and/or a stable system) and increase communication and advertising.

doktor5000 wrote: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.


I like to have updated packages but I also like to have a stable system so it's a matter of compromises or choices.
As I said, many users of other distros do not use Mageia because it does not provide updated packages or because they do not know this distro at all.
I agree with using flatpak to make up for the lack of packages, absent or not updated, but not everything can be in the form of flatpak. For example kde plasma on Mageia is at version 5.27 while currently we are at 6.3.5 and between the two versions there are notable differences.
Many new users seeing an outdated desktop do not proceed further even if the system is the best there is. This is a provocation but users looking for ultimate stability generally install Debian.


Another idea, what if we packaged all the system software as a flatpak, distributing it with a dedicated repo to go alongside flathub?
elementaryOS is doing the same.
irondave
 
Posts: 9
Joined: Mar 19th, '19, 20:35


Return to Ideas and suggestions

Who is online

Users browsing this forum: No registered users and 1 guest

cron