[Mageia-dev] Proposal: Updating released versions (long post)

[andré]

Frank Griffin a écrit :
> Part of the recent thread about what the desirable release cycle should
> be devolved into a discussion of how backports works and whether or not
> it's suitable.  I'd like to examine this issue.
>
> The current urpmi repository architecture serves purposes that were
> meaningful to Mandriva.  It segregates main from contrib for statement
> of support reasons, it separates non-free from main for philosophical
> reasons, and it separates restricted from main for legal and business
> reasons.
>
> This works pretty well for cooker, where you either want a particular
> category of package considered or you don't, but the reuse of this model
> for updates, backports, and testing in released versions isn't as good a
> fit.
>
> The root of the problem is that the user base is different.  Users of
> cooker want the latest and greatest of everything, and have accepted
> that if something breaks in cooker, it may stay broken for awhile.
> Users of released versions vary all over the map, from people who never
> want anything to change to people who want some specific updates to
> people who want everything new but want it stable.  Users of cooker
> rarely think about security updates, because in grabbing everything
> available constantly, the security updates are "just there".  With users
> of released versions, they may have to opt-in for security updates, and
> usually want to treat other updates differently.
>    
But wouldn't most users of cooker just take some packages from cooker to 
install on their stable release ?  Even if it's a computer used only for 
testing purposes ?
> I'd like to propose the following model for updating released versions:
>
> 1) Users should not have to see, except in minor ways, the different
> repositories.  Urpmi may see them, and advanced or ideologically polar
> users may care about them (e.g. free vs non-free), but most users
> won't.  Instead, let urpmi or rpmdrake have knowledge about all
> repositories whether enabled or not, and display the offerings with an
> icon, tooltip, or extra column that indicates the status of the package.
>    
Lets assume that the GUI rpmdrake is used.
Instead of hiding the repositories (or partially hiding them as now done),
let's display the current selection on entering rpmdrake, BEFORE taking 
the time to load and analyse the list of packages installed and 
available on the selected repositories.
Add a checkbox to update for each repository.
They should be listed with a brief description, or have a description 
available with context help.
The user then adjusts the selection as desired, before the loading/analysis.
If the user doesn't want to change the selection, they just press return.
Quick, easy - and the user always knows the options available and what 
is selected.
And indeed, in the package list displayed it would be useful to have a 
column for the source repository.
> 2) The update tool we give these users should distinguish between
> security updates and backports/testing, but present them both.  This is
> very much like the Windows Update model, where all available fixes are
> divided into "Critical System Updates" and "Software Updates".  We don't
> really have the same support constraints as Mandriva, and there's no
> need to automatically disable backports across the board, and not even
> present the backports as possibilities.
>    
With a column displaying the source repository, only an option to 
display updates is necessary, instead of the current "all updates", 
"security updates", "correction of anomolies", and "general updates".
I would keep backports separate, as they are necessarily more problematic.
However I would make the remaining display options with checkboxes : 
all, meta packages, graphic applications, updates, and backports.
as well, I would add all/installed/non-installed options to each line.
All these options to remember the last selection, for ease of use.
This way, the user sees all the display options in an easy to follow table.
> 3) Users should be able to enable options for each category
> independently.  Most users would probably want security updates applied
> automatically, but would want to be notified of availability of
> backports or testing and choose those manually.
>    
For automatic selection of packages to install, that is how it works 
now, which is fine.  But the user should always have the option to 
override the automatic selection.

For example, gedit, the gnome default editor has an extention where the 
latest version doesn't work properly for my purposes.  An automatic 
update installs the newer version, every time there is any type of 
update to gedit.  I had to use certain options of the command-line tool 
to override this to reinstall the working version.  And have to ensure 
that the non-working extension is not installed during updates.

BTW, a feature to blacklist the installation of a particular version of 
a package would be very useful.  I.e. an option "never install this 
package" or "never select automatically this package".
This would prevent a package found to be problematic on a particular 
system from being accidentally later installed on the system in question.

- André (andre999)