[Mageia-dev] Proposed Feature:Backports_update_applet

Sat Jun 9 22:53:39 CEST 2012

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 :)
+- 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.
+
+- 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.
+
+- Functioning as an update, it would only replace already installed 
+backports, once the tools are appropriately adjusted.
+
+- As with any update repo, one could always explicitly install a 
+backport which is not already installed.  No special treatment is 
+required for this.
+
+- using "bp" in the file name is nice and short, and definitively marks 
+it as a backport for the tools, and for the user once installed.  (I 
+would put it in the revision field.)
+I like this approach, as it doesn't matter from where the package is 
+installed; it will always be recognized as a backport.
+
+So I'm suggesting a variation of the last 2 solutions.
+I think that this would be relatively easy to implement.
+The trick is to find the right place in the code for the tweaks.
+(tv could probably do it really fast.)
+
+-- 
+André
+
+