Ubuntu Wiki

Abstract the sources.list for the user

Rationale

Currently the user interface of the sources.list configurator follows the concept of the sources.list file itself. Each deb line is one row in a listview. Furthermore enabling and disabling of components has to be done for each repository - the same situation applies to source code. We assume that if a user wants to use community maintained software (universe) from dapper, he or she would also likes to get updates and security updates for them if updates are enabled for main. Many users cannot make a clear difference between the terms repository, channel and component. Errors can be found in several wiki pages and howtos. So it would be good to completely hide this technical terminology and concepts for the user at all.

An abstraction of the Ubuntu repositories cannot be solved inside of a simple listview. A repo for "ubuntu 6.06 lts" would have got the following options: main, universe, multiverse restricted, source code, security updates, updates and backports. They need to be separated further. Furthermore the options of a repo depend on the repo and should not be represented at the the same level. Watch this demo of my former approach, that tried to go with a listview.

There is no need for adding Ubuntu sources in the user interfaces, since we rewrite the sources.list in dist-upgrader and there is a hal handler for inserted Ubuntu cdroms. So we only have to provide an add button to add third party repositories.

Use cases

1. Sebo wants to install software from the universe repository. So he has to enable this component (for dapper, dapper-updates and dapper-security).
2. Julia is a freedom lover and so wants to disable the restricted repository (for dapper, dapper-updates and dapper-security).
3. Felix hasn't got an internet connection, since the computer contains very sensitive data. So he wants to turn off all internet repositories and all updates.
4. Tom only has got slow modem connection. To save bandwidth he wants to skip updates and only get security fixes.
5. Maria downloaded a sources.list with third party repositories that she wants to use.
6. Hashimian wants to install software, but the Trukish mirror is down. So he wants to change to the main server.
7. Kurt uses 5 third party repositories (which is quite common if you take a look at the commited sources.lists in lp). So his repositories lets is quite long and complex: dapper, dapper-security, dapper-updates, dapper-backports, dapper (src), dapper-security (src), dapper-backports (src) + 5 additional repos.

Scope

gnome-app-install / app-install software-properties

Design

We introduce a concept of child repositories that share the same components with their parent repository e.g. software-properties uses the same components of dapper also for dapper-security, dapper-updates, dapper-backports.

The dialog will be renamed from "Software Settings" to "Software Sources" - this makes clear that you only choose from where to install software and do not manage which software is currently used by your system.

The configuration of the Ubuntu software will be completely moved from the listview to normal widgets on a notebook to workaround the limitations of a listview:

The first tab "Ubuntu Software" contains the configuration for the current Ubuntu release. The distro gets detected by lsb_release. The user can enable the different components of the Ubuntu repository, choose between the main server, the nearest server (using the locale information) and a custom one if specified.

All update related options are grouped on the second tab "Ubuntu Updates": enabling/disabling of security, updates and backports as well as of automatic updates and corresponding options.

Additional repos are all in the third tab "Additional Software" that still uses the listview. Third party repositories will be shown using a human readable label e.g. "Omnis Studio" instead of "deb ftp://ftp.omnis.net/ubuntu/ /". CDROMs and third party repos cannot be modified.

sources.list files can be handled by mime-type and drag&drop on the software-properties dialog.

So the workflow of the above use cases would be:

1. Sebo chooses System->Administration->Software Sources and checks "Free software that is maintained by the community (universe)" in the Ubuntu Software section.

2. Julia chooses System->Administration->Software Sources and unchecks on "Non-free driver for devices (restricted)" in the Ubuntu Software section.

3. Felix chooses System->Administration->Software Sources and unchecks "Internet" in the Location section.

4. Tom chooses System->Administration->Software Sources, clicks on the "Ubuntu Updates" tab and unchecks "Security updates" and "Suggested updates".

5. Maria double-clicks on the file. A dialog pops up showing a list of the included repositories and providing an option to enable this repositories.

6. Hashimian System->Administration->Software Sources and chooses "default server" in the Location section.

7. Kurt chooses System->Administration->Software Source and gets a list of all his third party repositories in the tab "Additional Software".

Implementation

There is already a modified version of aptsources.py that can handle parent/child repositories, but didn't make it into dapper. Human readable descriptions of repos and relations can already be stored in info files (DistInfo.py of UpdateManager is reused for this). We can easily extended this by the descriptions of third party repo from app-install.

The user interface was discussed with EllenReitmayer.

Talked with Jane about the disclaimers at Paris.

Some mockups from UDS Paris:

Screenshot of the current version (30.6.2006):

Code

SoftwarePropertiesUDSParis.glade

Development takes place in my brz branch:

http://pimpzkru.dyndns.org/~sebi/devel/update-manager/repo-rewrite

that is also mirrored on launchpad:

https://launchpad.net/people/glatzor/+branch/update-manager/repo-rewrite

Data preservation and migration

A main focus is on not destroying a custom configurtation of the sources.list. Therefore the corresponding checkboxes would be set to inconsistent (represented by a minus in the Clearlooks theme) if the configuration cannot be represented in the user interface. E.g. if the dapper repo uses main and universe, but there are only dapper-updates for main, the checkbox for "Suggested updates" will be inconsistent. I don't plan to add nag screens about missing components for dapper-updates or dapper-backports, since this was an explicit decision by the user. I am still unsure about dapper-security.

Outstanding issues

• How to handle cdrom sources? Perhaps it would be good to show them in the listview, since different update cds are planned for edgy (language packs, point releases)
• Better label for the backport component - talk to docu team

BoF agenda and discussion

CategorySpec