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é
