[Mageia-dev] Various proposals around backports and other media management

[Samuel Verschelde]

Hello to everyone on the list,

As some people said in another thread, Mandriva's current media schema already gives the opportunity to :
- install newer versions of software if needed (from backports media),
- keep a stable system with only security fixes if needed (updates media, for servers or any workstation where stability counts more than being bleeding-edge)

However, we can improve things around backports, updates, testing and debug media for the end user's benefit.

I'd like to propose the following improvements if you think they would be good (and I'm ready to help make them happen) :


- a section on the mageia website dedicated to package updates : what's new in security/bugfix updates, what's new in backports (aka version updates), ... with screen captures, description of what changed in this version, links to upstream websites, comments from users, focus on some applications... Some user communities already did that for 3rd party repositories for Mandriva, and having it in a centralized and visible place would make backports more visible. How many users know that latest versions for wine, wesnoth (one of the best opensource games), vlc, and many other packages are already available in backports media for mandriva ? Today there is a changelog mailing list, but this is not for everyone.
This would be more user-centric than packager-centric. I tried to improve backports visibility on the Mandriva forum, but without any automation it took an enormous amount of time to maintain :
http://forum.mandriva.com/viewforum.php?f=123 (see threads beginning with "New Soft" or "Backport")


- add a "welcome" screen to rpmdrake, where people could choose between :
 * Browse and install security / bugfix updates
 * Browse and install new versions of software ("backports")
 * Install new software
 * Uninstall software
 * Skip this newbie step and get me to the real stuff, I'll use the various options to do what I need
Rpmdrake can also be enhanced to show for each package update whether it's a backport or a standard update. It's not easy currently (you have to dig into package details).


- (the biggest part, but the one with most long term benefits I hope) add metadata to media to make urpmi more media-aware. Today, rpmdrake detects backports because the backports media have "backports" in their name. That's a (useful) hack, but we could do better. One solution could be to give metadata to each media :
 * release vs updates vs backports
 * testing vs stable
 * debug vs non-debug
Combination of these "tags" would give the following media :
    * main release (just like today's media)
    * main updates
    * main updates testing : for update candidates, this is our current "main testing" media
    * main backports 
    * main backports testing : for backports candidates (as someone who frequently does backports, I sometimes feel the lack for it)
    * main release debug...
    * contrib...
    * non-free... 
It may seem a lot of media, but in fact you have to think they all are only flavours of the main, contrib, non-free, and other media. We can think of a better presentation in UI tools that will in fact make them appear less cluttered than it is today : 
http://stormi.lautre.net/fichiers/mageia/media-configuration-proposal.ods

In CLI, urpmi would default to using only release and updates media (which you could change in configuration if needed), and you could use other media with the following switches for example :
--use-backports : enables all backports media
--use-testing : enables all testing media
--use-debug : enables all debug media

This way, no one would have to activate/unactivate the various media globally anymore. Let's say you need to test the latest vlc backport before it goes to "stable" backports. You'll type : urpmi vlc vlc-debug --use-backports --use-testing --use-debug and voilà ! No need to temporarily activate backports, testing and debug media globally, or specify every media manually via the --media switch.

To not put too much burden on mirrors, packages going from a testing media to an non-testing media would be removed from the testing media.


This proposals are open to discussion, of course, as I have no power of decision and may be wrong. I guess there may be several weak points in my view, but I'm sure there are also strong points.

Regards

Samuel Verschelde