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

Reply via email to