Samuel Verschelde a écrit :
Le mardi 28 juin 2011 03:44:24, andre999 a écrit :
2) Backports would not be removed from repos when a newer backport arrives,
except those affected by security updates.
This allows reverting to previous backports if a user finds a problem with
a backport on their system.
I'd prefer that we don't keep multiple backports versions in the repositories,
for the sake of simplicity. Users who ask for the latest must accept that
sometimes the latest is not the greatest. Plus, we have the backports_testing
repos so that users can test and spot bugs before the old backport is replaced
with the new one.
I want stable : don't use backports.
I want the latest : use backports.
I want an intermediate version : no, sorry, your need is too specific. You can
still compile it.
I'm trying to consider the needs of a typical backport user, who needs to revert
to a previous version of a backport already installed, due to problems with a
newer backport.
A problem which will often affect only some users installing the particular
backport.
They won't activate the backport repository. So when installing backports, they
will only see a list of backports (at least via rpmdrake).
They are not necessarily familiar with compiling (unlike most of us).
Suppose for a package release A we have issued backports B and C.
If B causes problems on a particular system, the user reverts to A.
No problem.
If a user has installed B, which worked well for them,
and subsequently installes C which has problems,
they would like to revert to B.
(Reverting to A could cause a loss of data as well as functionality.)
So why tell the user that they can't revert to a backport version that already
worked for them ?
I would suggest a message such as :
"users installing backports should install the latest version for the package
unless they need to revert to a previous version due to problems"
(To appear only when they have chosen to install backports.)
I realise that this complicates the presentation, and maybe another solution
could be found.
(For example, saving all backports packages installed on a system, so that they
can be reinstalled.)
(A case-by-case analysis of new backports could show which previous backports
could be safely removed, for minor changes such as simple bug fixes.)
Or maybe make these backports only visible with urpmi, so that users of the
graphic interfaces won't see them. (As someone else suggested.)
This would of course require the graphic interfaces to avoid displaying these
older backports, but would provide the other advantages of keeping the backports.
Keeping previous backports would facilitate producing security updates for all
backports actually installed on various user's systems.
This adds some complexity for security updates, in exchange for greater
security.
Samuel
--
André
