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é
