Package Management Tool Functional Spec

Scenarios

The following scenarios attempt to represent typical users and how they might use the Package Management Tool. Once a mockup of the interface is finished, how the users solve the problems represented in these scenerios will be added.

The following people are figments of Tammy's imagination. If they resemble any real people, it is complete coincidental.

Scenerio 1: Joe is an software developer who uses Fedora Core at home to learn how to program in a Linux environment so that some day he can find a job as a Linux software developer. Shortly after installing, a security errata is released for his system. He wants to upgrade to the errata packages immediately.

Scenerio 2: Caroline is a college student who uses Fedora Core on her computer. She reads about a cool new Linux program that can calculate differential equations. She wants to try out this new program for http://www.fedora.us.

Scenerio 3: Tony is a system administrator for a medium-sized corporation and maintains a group of Fedora Core systems. He needs a process for keeping all his Fedora Core system updated with the latest errata packages.

Scenerio 4: Sal is a hobbyist Fedora Core user who uses it at home in his spare time for fun. Sal reads about a program called Tripwire and wants to install it and try it out.

Scenerio 5: Betty is a hobbyist user who performed a Desktop installation. She reads about the KDE desktop environment and wants to install it from the Fedora Core CD-ROMs.

Tasks

The following tables represent all the tasks a user might want to perform for packages along with a priority number. The priority number represents how important it is that the task be implemented in the Package Management Tool, with 1 being the highest priority. The number of clicks represents the number of clicks it takes to complete the task based on the latest mockup. (The number of clicks will be filled in when we have a working mockup.)

The priorities still need to be broken down into goals for Taroon, goals for Cambridge, postponed, and won't fix.

Non Goals

The following will not be implemented:

• Filtering flat list of packages

• Downloading but not installing RPMs or SRPMs

• Downloading or installing SRPMs

Outstanding Issues

• Debug packages will be in their own RHN channel eventually so people can download and install them if they want to via the Package Management Tool, and Package Management Tool doesn't have to do anything special to handle them.

• Comps does not include all packages -- all packages are not displayed in group view, but are in flat list

• Blacklist of packages not to be removed is complicated. Worst case, we show all installed packages on the Remove Packages page and warn users if they try to uninstall on on the blacklist.

• Community sites such as fedora do not have a standard format or comps file. We have to write a document describing the standard format for these and update CDs.

• What if package dependencies are not found for a non-RH package?

• What if a non-RH package requires a newer version of a RH package, but the newer version is not available from RH? It can not automatically upgrade from a RH-package to a non-RH package because support by not support the user after that. Maybe is should warn the user before upgrading?

• Should flat list of packages to be removed include package size?

• How to display the same package for mulitple arches in the same software location

• For systems subscribed to a third-party RHN channels, how do they add a package from the channel.

• How does the tool determine updates from other non-Red Hat locations

• Is a package group still installed if one or more mandatory packages for that group is not installed?

Expected Behavior

The following is a summary of key points:

• Localized human-readable package names that match the desktop files (This is not targeted for Cambridge and Taroon, but will need to be implemented at some point in the future.)

• When the Package Management Tool is launched, if it is registered with RHN and if updates are available, prompt the user to install the available updates with the dialog shown in Figure 5.

• RHN notification icon starts dialog with list of available updates and button to apply them as shown in Figure 5.

• If a package is selected to be added, and it has an errata update, automatically install updated version. This means that the list of packages to add must show the updated version number.

• Updates list will show Red Hat updates from RHN as well as updated packages from third-party sources added as package locations.

• The preferences will be set from within the main program, not a separate program or menu item.

• If a package is not in a comps group, it will be listed under a group called Unclassified.

• Before installing, it will attempt to verify the signature of the package. If it can't be verified or if the package is not signed, it will prompt the user to make sure he wants to install it anyway.

• Changing Views:

  • If changes within the view are not yet applied and the user selects a different view, the changes are remembered but the other views are not affected by the change because they are not yet applied — When the user returns to the view, it still has the changes.

  • The button on each view will be labeled with the action that can be performed from that view. It will only apply changes made within the current view, not changes made on other views but not applied. In other words, you can not install or remove packages at the same time or install/remove package groups at the same time. To the left of the button will be the number of packages to be installed or removed according to the changes made within the current view.

  • No popup dialog will be displayed if the view is changed but the changes are not yet applied.

• If a Documentation CD or third-party CD such as an Oracle Installation CD is inserted, the window that looks like the Add Package Groups view of the Package Management Tool will appear, and the following rules will apply:

  1. If the CD contains a valid comps file as defined by Red Hat:

     • The packages on the CD will be displayed in the groups defined in the comps file from the CD. If only one group exists in the comps file, the groups header will not be shown; instead, a flat list of all the packages in the one package group will be displayed.

     • The comps file from the CD will be incorporated in the comps file on the system so that the packages from the CD will appear in Package Management Tool even if the CD is not mounted on the system when the tool is started.

     • Any packages on the CD but not in a category in the comps file will be listed under a package group called Unclassified.

     • All packages not already installed will be pre-selected.

  2. If the CD does not contain a valid comps file:

     • A list of all the packages on the CD will be displayed in a flat list with no package group header.

     • The list of files will be added to the comps file for the system under the Unclassified category so that the packages are shown the next time Package Management Tool is started.

     • All packages not already installed will be pre-selected.

The popup dialogs consist of the following. They should be kept to a minimum.

• Progress bar

• Conflicts

• Packages need to resolve deps

• Package list from details button of group

• Package is not signed or signature could not be verified

• Erratum details

Look and Feel

The graphical interface will use the Bluecurve^TM colors and look and feel as much as possible.

The menu item and the window titles will be Add and Remove Software.

The user should be able to select a task from a taskbar on the left side of the dialog. The rest of the dialog will change depending on which task is selected.

The following images represent the placement of the widgets and wording of the text; the colors and graphics are not final. More colors will need to be added to the Bluecurve^TM color list for the view highlight color, etc. to make them more subtle.

Preferences

The user will be able to configure the following preferences for Package Management Tool:

• Specify an additional source location such as an FTP site, a directory containing an installation tree, and a directory containing the ISOs.

  There will need to be some default package locations in the list. The user will be able to add, edit and delete package locations.

• Configure list of packages to skip when upgrading

• Configure proxy settings (no system-wide proxy settings)

The following preferences will not be available to configure:

• Whether to prompt for updates (updates include any newer package from all specified source locations)

• Whether to download the RPMs but not install them

• Whether to download the SRPM