[Mageia-dev] Proposed Feature:Backports_update_applet

Tue Jun 12 07:36:27 CEST 2012

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