[Mageia-dev] Proposed Feature:Backports_update_applet

Tue Jun 12 12:31:05 CEST 2012

blind Pete a écrit :
+> andre999 wrote:
+>
+>    
+>> blind Pete a écrit :
+>>      
+>>> Samuel Verschelde wrote:
+>>>
+>>>
+>>>        
+>>>> Following Backports opening due soon, and since our policy is that
+>>>> backports are supported (security, bugfix), we need a way to push
+>>>> backport updates for users who installed backports. Otherwise, we can't
+>>>> really say that we're providing security updates to our backports.
+>>>>
+>>>> My feature proposal is to implement something similar to what mgaonline
+>>>> + MageiaUpdate does for updates, but for backports, with some changes
+>>>> due to the fact that users will rarely want that "all" packages on the
+>>>> system be updated from backports when the backports media are activated.
+>>>>
+>>>> https://wiki.mageia.org/en/Feature:Backports_update_applet
+>>>>
+>>>> I don't think I can do the dev myself. I can work on more detailed
+>>>> specifications with a developer though.
+>>>>
+>>>> Samuel
+>>>>
+>>>>          
+>>> There are a multiple ways that this problem could be handled.
+>>> Yours is one.
+>>>
+>>> Samuel's way:
+>>>
+>>> Need "something" to know that a backport package
+>>> has been installed, to remember that fact, and to do an extra
+>>> backport update search when looking for updates.
+>>>
+>>> It would need to keep working if the user changed desktop
+>>> environments, or even stopped used a desktop and just used
+>>> the command line.  Does mgaonline do this?  There could be
+>>> room to improve that.
+>>>
+>>> If it can be detected that a backport package has been installed
+>>> (or less efficiently, detect that a backports repository
+>>> has been activated) set up a cron job (or reconfigure mgaonline)
+>>> and leave it like that for the life of the installation.
+>>>
+>>> Geeks way:
+>>>
+>>> Only use urpmi as a command line tool and edit urpmi.cfg with vi.
+>>>
+>>> When activating a backports repository mark it as an update
+>>> repository.  Then update with "urpmi --excludemedia [backport media,
+>>> ...]" accepting all suggestions, followed by "urpmi --auto-select"
+>>> and look at what is offered before accepting.
+>>>
+>>> My suggestion:
+>>>
+>>> Add "bp" to the package name and have separate backports update
+>>> repositories.
+>>>
+>>> Users would then be able to cherry pick from backports and
+>>> updates should _just work_ without extra intervention.
+>>>
+>>> The only difficulty that I can think of is, when a backport
+>>> (or backport update) package is pushed to updates.  It would
+>>> not be necessary to do a real update but the rpm database
+>>> should be updated such that version N-bp supersedes version N.
+>>> (And the N-bp packages should be removed from the repositories.)
+>>>
+>>> Can anyone see any holes in the logic?
+>>>
+>>> What would be easiest to implement?
+>>>
+>>>
+>>>        
+>> You got me thinking :)
+>>      
+> Thinking is always dangerous.  ;-)
+
+I guess I like living dangerously :)
+
+>> - Just marking all backport repos as update repos is almost enough to
+>> solve the problem, in terms of the tools installing the backports.
+>> Great idea !
+>> We just have to tweak the tools so that a backport is only installed as
+>> an update of a backport.
+>>      
+> Because the contents of the backport repositories changes during
+> the life of an installation it is desirable to... well... um...
+> "update" the database about that.
+>
+>    
+>> - Note that we should allow a non-backport to replace a backport, as
+>> will likely be encountered in a release update.  If the versioning is
+>> properly done (according to established packaging policy), a
+>> non-backport in a newer release will have a higher version number, thus
+>> replacing the backport.
+>>      
+> If they had the same version number you would not want to do a
+> real update, but you might want to adjust the database.  I have
+> no idea if that would be more trouble than it is worth.
+
+Presently on a release update, all packages are replaced (if they exist 
+in the release), even if they are updates identical to the package in 
+the release being installed.  This is (at least in part) because we 
+ensure that the update has a version number (counting the revision) less 
+than that of the release.
+It shouldn't be different for backports.
+
+>> - Functioning as an update, it would only replace already installed
+>> backports, once the tools are appropriately adjusted.
+>>      
+> There are a couple of ways to do that.  The simplest that I can think
+> of is to split "backports" into "backports" and "backports update".
+> Allow cherry picking from "backports" and apply "backports update"
+> automatically.
+>    
+
+I was thinking of cases where the user chooses to "update" their 
+system.  New versions of backports already installed would be presented 
+as updates, along with those from the update repos.
+Just as we don't have any update-update repos, it wouldn't make sense to 
+have backport-update repos either.
+Not every user would choose to install every proposed update from the 
+update repo.
+In such cases, the update is proposed the next time the user asks for 
+updates.
+Similarly, available backport updates won't necessarily be installed the 
+first time, but should be proposed the next time the user asks for updates.
+
+I would favour these backport updates being offered even if the backport 
+repos are not active.
+However to see all backports, in normal install situations, it makes 
+sense to require that the backport repos be active.
+When the backport repos are active, during updates we could even show 
+backports as updates to non-backport packages, but I'm not sure that I 
+would favour that.  I would prefer the installation of a backport to be 
+more of an exceptional case.  My impression is that most users tend to 
+install all updates presented, without necessarily thinking of the 
+consequences.
+
+-- 
+André
+
+