Identifying Primary Packages

Status

• Created: 20/04/05 by MarkShuttleworth
  

• Priority: LowPriority
  

• People: MichaelVogtLead, DanielHolbachSecond

• Contributors: MarkShuttleworth
  

• Interested:
  

• Status: EditedSpecification, DistroSpecification, MarkShuttleworthQueue
  

• Branch:
  

• Malone Bug:
  

• Packages:
  

• Depends:
  

Introduction

This specification describes a way of categorising packages so that people can be presented with a more straightforward package selection. Currently, Ubuntu main consists of well over 1,000 packages. The goal of this specification is to reduce the normal default package list to around 200 packages, by choosing not to display libraries and developer packages.

Rationale

With the number of packages formally supported by the Ubuntu team growing every month, we need to find ways to make it easier for users to find the package they are looking for. One way to do this is to show only the "primary" packages by default, where "primary" denotes a package that is not a library or dev or doc package.

In some cases, a library could be a primary package in its own right, but in general it's unlikely that an end-user would be looking for a specific library. End-users are more likely to be looking for applications and utilities, so we would like to present a list that by default is limited to those "primary" applications.

Scope and Use Cases

We have around 3000 binary packages in main right now. When we cut out "libs, devel, doc, tex and translations" we still have around 1500 binary packages. Most packages with .desktop files in them are likely candidates for primary packages because they are applications that the user uses directly. Other likely candidates are server programs (like samba, apache). Other likely candidates can be found by looking at the distribution seeds files (http://www.ubuntulinux.org/wiki/SeedManagement).

We want to display those primary packages in a special package install application (that was discussed in the FindingPackages BOF).

A use case is: Klaus wants to install a cd burning application. He is not interested in all the libs/doc packages but only wants to install the application.

From a stability/support point of view primary packages should be used to make a commitment to the users that those applications are not removed from the next version of the release. Before a removal the application needs to be marked as deprecated for one release (6 months). This does mean that certain libraries needs to be marked as primary packages too (e.g. gstreamer) and kept API/ABI compatible. We probably do not want to show this libraries in a package selections GUI.

Implementation Plan

The primary packages needs to identified by the means described above. This list is then used in the special application install application. A similar list is useful for universe. Here we want to split that list up into various subcategories (e.g. "games"). This needs to be done by the MOTU teams (e.g. the MOTU game team). We may review the top 25% of http://popcon.ubuntu.com/universe/by_inst to see what is interesting for universe.

Packages Affected

All the packages in main needs to be reviewed and a list compiled from them. Some of the data can be gathered automatically, but it needs to be reviewed by hand.

User Interface Requirements

Identifying the packages does not requires a user interface. The primary packages will be displayed to the user by a enhanced version of gnome-app-install as described in FindingPackages. The primary packages should probably have i18ned descriptions to make the access for non-English speaking people easier.

Outstanding Issues

No work in this area was done so far.

CategoryUdu CategorySpec