[Mageia-dev] Proposed Feature:Backports_update_applet
andre999mga at laposte.net
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.
>>>> I don't think I can do the dev myself. I can work on more detailed
>>>> specifications with a developer though.
>>> 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
>>> 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"
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
In such cases, the update is proposed the next time the user asks for
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
More information about the Mageia-dev