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

Sat Oct 9 16:41:26 CEST 2010

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)
+