Tools/MandrivaUpdate/Usecases
From Mandriva
This page describes the usecases for the MandrivaUpdate tool.
From the User point of view:
- Consult the list of available updates
- Install a selection of available updates
- Configure the source of updates
From the System point of view:
- Automatically download available updates
- Automatically install available updates
Note: a usecase is a functionnal specification of the intented behaviour of an application. For more information, consult: http://alistair.cockburn.us/usecases/usecases.html
Default failure condition: an error message indicating the origin of the failure is presented to the user; other failure conditions may apply to specific usecases. Note: this means that whenever an error occurs in a defined error path, the system MUST display an error message to the user.
Use Case: Consult the list of available updates
Description: the user starts Mandriva One to use its computer Actor: the user (currently using the desktop session running on the system) Pre-conditions: not applicable Success condition: a list of packages or an information message (no updates) are presented to the user
Main success scenario
- The system displays an indicator to explain that it is looking for available updates
- The system searches in each configured media for available updates (see definition below)
- The system display the list of updates
- The user can select an update to display more information about it
- The system displays detailed information about an update (ie its 'description') stating what changed
Note: by default, the list of "configured media" eligible for an update search only contains official Mandriva medias.
Alternative success scenario
- The system determines that there are no updates currently available
- The system displays a message stating that no updates are currently available
Note: the information message should not be a popup, as this is not an exceptional or error condition.
Additional specifications
An updated package is a package that does meet the following criterias:
- a local version of the package is installed on the system
- there exists a new version of the package, listed in some accessible media declared on the local system (urpmi.cfg), whatever 'update' flag there is
An official update is a package that is considered an update by the previous definition, AND is also listed in the "descriptions" file, ie there is an errata entry associated with it.
Applications can try to optimize display and shorten startup time by only checking for updates in so called 'update' medias. Yet, they should be able to scan other medias in the background and refresh the list after a while. Other optimizations can be implemented to avoid checking non-update medias for which the hdlist/synthesis was non changed since the last run.
User interface
When a background lookup operation is performed, the user interface must notify the user that such an operation is in progress.
The system can refresh the list of packages progressively while it does perform the search to improve application interactivity.
Use Case: Install a selection of available updates
TBD
Use Case: Configure the source of updates
TBD
Use Case: Automatically download available updates
TBD
Use Case: Automatically install available updates
TBD
Other notes (gathered from emails and IRC chats)
If a user selects a media like 'contrib/updates' it would be crazy not to take it into account. And if he selects just 'contrib' we should ask if he also want to subscribe to the associated 'contrib/updates' channel. The same applies for other medias like non-free, restricted, etc. To better show the difference between /official/ updates and unofficial and or unsupported packages, rpmdrake should display a small 'mandriva star' tag next or over the package line to highlight its status.
[09:39] <AdamW> dbarth: so you're saying it's okay that a user who adds a 'testing' media on instructions from one of us, in order to test one specific update (say they reported a bug and we asked them to test the candidate fix), will see all future /testing packages as bona fide updates from MandrivaUpdate? I can't agree with that. [09:40] <dbarth> AdamW: no, what i'm saying is that a tool must have a predictable behaviour [09:41] <dbarth> AdamW: it cannot behave differently wether the media is called 'a' or 'b' [09:41] <AdamW> but mandrivaupdate is supposed to be specifically about providing recommended security updates, not just any package in any defined urpmi media which happens to be newer... [09:42] <dbarth> AdamW: to take this 'testing' case into account, i propose we explicitely ask the user if he wants to also subscribe to the related 'updates', 'testing' or 'whatever' sub-channels [09:42] <dbarth> and for mandrivaupdate, the default configuration can be to only install official updates, as this tool is supposed (sigh...) to work automagically in the background [09:42] <AdamW> that's good (actually i've wanted rpmdrake to do that for a while) [09:43] <AdamW> but i'm still not so happy. i mean, if *i* were running 2007, i'd probably have /testing and /backports media defined. [09:43] <AdamW> but I wouldn't want mandrivaupdate to show those packages. [09:43] <AdamW> i'd handle them with rpmdrake or urpmi. [09:43] <AdamW> i'd want mandrivaupdate as an easy way to install the safe, recommended updates. [09:43] <dbarth> AdamW: that is what i'm saying [09:44] <AdamW> ok, maybe we're misunderstanding each other then :) [09:44] <dbarth> AdamW: fine [09:44] <AdamW> you mean you'd have rpmdrake, in its mandrivaupdate mode, ask whether to show the /testing and /backports packages or not?
