Frank Griffin a écrit :
Part of the recent thread about what the desirable release cycle should
be devolved into a discussion of how backports works and whether or not
it's suitable. I'd like to examine this issue.
The current urpmi repository architecture serves purposes that were
meaningful to Mandriva. It segregates main from contrib for statement
of support reasons, it separates non-free from main for philosophical
reasons, and it separates restricted from main for legal and business
reasons.
This works pretty well for cooker, where you either want a particular
category of package considered or you don't, but the reuse of this model
for updates, backports, and testing in released versions isn't as good a
fit.
The root of the problem is that the user base is different. Users of
cooker want the latest and greatest of everything, and have accepted
that if something breaks in cooker, it may stay broken for awhile.
Users of released versions vary all over the map, from people who never
want anything to change to people who want some specific updates to
people who want everything new but want it stable. Users of cooker
rarely think about security updates, because in grabbing everything
available constantly, the security updates are "just there". With users
of released versions, they may have to opt-in for security updates, and
usually want to treat other updates differently.
But wouldn't most users of cooker just take some packages from cooker to
install on their stable release ? Even if it's a computer used only for
testing purposes ?
I'd like to propose the following model for updating released versions:
1) Users should not have to see, except in minor ways, the different
repositories. Urpmi may see them, and advanced or ideologically polar
users may care about them (e.g. free vs non-free), but most users
won't. Instead, let urpmi or rpmdrake have knowledge about all
repositories whether enabled or not, and display the offerings with an
icon, tooltip, or extra column that indicates the status of the package.
Lets assume that the GUI rpmdrake is used.
Instead of hiding the repositories (or partially hiding them as now done),
let's display the current selection on entering rpmdrake, BEFORE taking
the time to load and analyse the list of packages installed and
available on the selected repositories.
Add a checkbox to update for each repository.
They should be listed with a brief description, or have a description
available with context help.
The user then adjusts the selection as desired, before the loading/analysis.
If the user doesn't want to change the selection, they just press return.
Quick, easy - and the user always knows the options available and what
is selected.
And indeed, in the package list displayed it would be useful to have a
column for the source repository.
2) The update tool we give these users should distinguish between
security updates and backports/testing, but present them both. This is
very much like the Windows Update model, where all available fixes are
divided into "Critical System Updates" and "Software Updates". We don't
really have the same support constraints as Mandriva, and there's no
need to automatically disable backports across the board, and not even
present the backports as possibilities.
With a column displaying the source repository, only an option to
display updates is necessary, instead of the current "all updates",
"security updates", "correction of anomolies", and "general updates".
I would keep backports separate, as they are necessarily more problematic.
However I would make the remaining display options with checkboxes :
all, meta packages, graphic applications, updates, and backports.
as well, I would add all/installed/non-installed options to each line.
All these options to remember the last selection, for ease of use.
This way, the user sees all the display options in an easy to follow table.
3) Users should be able to enable options for each category
independently. Most users would probably want security updates applied
automatically, but would want to be notified of availability of
backports or testing and choose those manually.
For automatic selection of packages to install, that is how it works
now, which is fine. But the user should always have the option to
override the automatic selection.
For example, gedit, the gnome default editor has an extention where the
latest version doesn't work properly for my purposes. An automatic
update installs the newer version, every time there is any type of
update to gedit. I had to use certain options of the command-line tool
to override this to reinstall the working version. And have to ensure
that the non-working extension is not installed during updates.
BTW, a feature to blacklist the installation of a particular version of
a package would be very useful. I.e. an option "never install this
package" or "never select automatically this package".
This would prevent a package found to be problematic on a particular
system from being accidentally later installed on the system in question.
- André (andre999)
