Ubuntu Wiki

• Created: Date(2005-10-07T12:45:59Z) by JaneWeideman

• People: JonathanRiddell, Petr Rockai

Summary

Kubuntu package manager tools for Dapper.

Rationale

Kubuntu Breezy added Adept, the first time KDE has had a first class .deb package manager. We should continue this work in Dapper.

Details

Adept

Adept 2.0 will add the ability to find more detailed package information including a file list, relations to other packages and available information. We should be careful here to do this in a way which does not crowd the user interface.

We will put Adept for a usability review on OpenUsability.org and implement any good suggestions from them.

Adept in SVN now creates .po files for translation, we will ship with these. We will also add i18n support to libapt-front for full i18n support in Adept. We will ensure Adept gets into Rosetta to make it easy for translators to use.

Package context menu will get "reinstall" and "purge" options.

By default the terminal that is used during commit will be hidden and a progressbar will be shown. A button will be present to show the terminal. Eventually, the terminal will be shown automatically if some program is waiting for input there (bar technical difficulties in implementing this).

Dependency tracking will be added pending this feature being included in libapt. This will allow for packages to be uninstalled with all the dependencies it brought in automatically uninstalled. In case libapt won't gain this feature, it will be postponed to adept 3.0 since at the time libapt-front will handle it, eventually.

A function will be added to summarise changes between cache states. This means, we can provide tooltips and the like for install/remove/... buttons that will tell the user what changes will be made to the system after that action is selected. Undo and redo functions shall get similar hints.

We will add the ability to set version/release policy (pinning). This is another case where care with the user interface will have to be taken as it is a complex area. Eventually, the detailed package view will get a "preferred release" combo, which will allow to select a release pin per package. More pinning options should be available through "system wide release/version preferences" (a pin editor, mostly) and through a per-package pinning dialog or (most probably) expansion.

Work is being completed on an advanced problem resolution algorithm in aptitide. This may be included in libapt. We will ensure this is supported in Adept if this happens. Note: however, the current aptitude algorithm is somewhat problematic. It may be so that the problem will be completely postponed to adept 3.0, together with package status tracking.

Update Notifier

Adept includes an update application to download and install the latest packages. We will create an update notifier to monitor the archive (and sources.list) and bring up a notification when there are updates which will prompt the user to run Adept Updater. Similar to the Ubuntu update-notifier ours should not keep a copy of the dpkg database in memory for longer than necessary.

The notifier should be a small system-tray applet that will display an "OK" (currently a green led) icon when the system is up to date and a "warning" (currently a red triangle with exclamation mark) icon when updates are available. The tooltip will show how many upgradable packages there are.

The applet works to minimize memory and resource use. Apt database is opened only on startup or when it changes. This is done by polling the cache timestamp, so we don't miss when user manually runs an update. Otherwise, we rely on the apt cronjob to pull updates.

When the applet is clicked, adept updater is launched, if there are updates available. Otherwise, a dialog box is shown saying there are no updates. On the right click menu, one can run the updater manually to check for updates. The only other actions shall be quit and help.

Simplified Installer

The simplified installer will have a wizard-style interface. It should have 2 modes of operation, one where the packages are presented in a way similar to gnome-app-install and one based on debtags. The latter one is questionable though, comments welcome.

Gnome-app-install interface: The presnted package list will reflect ubuntu menu structure, since it will be generated from the .desktop files shipped by gnome-app-install. It will show just checkboxes and everything else (namely eventual upgrades) will be handled behind the scenes. The current idea is to show a small blurb that says "additional changes need to be done to your system: <details>" where details brings the standard change-review screen of adept. We shall try to minimize risk of damaging the system, eg. by refusing to do installs that remove packages (other than those removed explicitly) without reviewal. Note that there will be a separate description pane for the package currently selected, apart from the package list.

Debtags interface: A trimmed down list of packages (only those that have KDE or GTK interface or are part of openoffice/mozilla/<any other important suite>) is presented, with a bunch of useful criteria to search in this list, based on available tags. The presented list may follow the kde menu structure (eg by shipping a tag file that adds info to packages about the menu section they belong to in kde). Icons and eventually other data may be shipped as well. The gnome-app-install database can be exploited too. However, this interface is probably a 3.0 material, yet to be decided.

If the debtags interface is available, the interface to use will be configurable through application's menu. The preference will be saved in a configuration file.

.deb installer

An installation wizard for single .deb packages should be created (to be run when user clicks a deb file in konqueror, eg). It will first of all copy the deb into a local repository, which is maintained by libapt-front internally. This way, the package will remain installable in case it is removed by the user. User will be hinted about this fact and Adept will eventually get an utility to manage this mini-repository (like clean it up). Alternatively, user may select to not keep the copy of the package in the wizard (then, only the Packages file of the mini-repository will be changed to point at the file in its current location... after finishing installation the reference will be removed again).

Then the cache is regenerated (the neccessity to do this is a design problem of libapt-pkg... it will be eventually addressed, but only in adept 3.0 (more like corresponding libapt-front version) or later). A normal apt-style (and adept-style) installation of the package is done then (allowing user to review the list of changes that will be done to his system, ala adept). Download of the dependencies and dpkg run will be handled likewise.

Target Feature Set

• detailed package view and package browsing interface
• further improved filtering ui
• pinning support
• full i18n
• purge and reinstall options in the UI
• konsole hiding
• individual deb handling
• simplified installer UI
• update notifier

All of these should be completed for this spec to be considered done. See rest of the spec for details on how individual items should look like and the roadmap for milestones and their features.

Implementation Notes

The adept-updater and adept code bases will be streamlined and common code pushed into libept (there's still some redundancy). This code may then be as well reused in the simplified installer. Any new features needed for the new utilities/applications will be carefully considered for inclusion in libapt-front, so everyone can benefit. If time permits.

The plan by APT team is to include new features in libapt-pkg, we will try to take advantage of those as much as possible.

Roadmap

[http://people.freedesktop.org/~mornfall/adept-tags.png screenshot as of 2005-12-12]

December 15th-20th: adept 1.88 (alpha 1)

• the most "intrusive" changes to ui should be done at this point: the detailed package view and package browsing interface, improvements to the filtering ui [filtering ui nearly done, browser nearly done]
• the ui should be fully i18n'd [done modulo few less important strings and the few strings from libapt-front; those shall be fixed in another alpha]
• skeleton of the update notifier should be done [done]
• purge and reinstall options in the UI [done]
• at least basic support for konsole hiding (eventually without "waiting for input" detection) [done]
• interruptible download, cancel button in media swapping dialog [done]

January 5th-12th: adept 1.89 (alpha 2)

• this should see completion of many of the "incomplete" features of the alpha
• pinning support
• installation of single .deb packages
• any new libapt-pkg features that we are interested in and are complete enough at the time should be at least partially supported by this alpha
• remaining "intrusive" usability issues are hopefully resolved (like error reporting in the fetcher)
• completion of update notifier
• introduction of simplified installer UI

February 9th-16th: adept 1.90 (beta 1)

• this version should be feature complete
• libapt-pkg new feature integration is finished
• any other slips or omissions from the second alhpa are fixed
• any serious bugs from alpha 2 get fixed here
• finishing the simplified installer

March 2nd: adept 1.91 (beta 2)

• fixes for any serious problems that appear in beta 2
• all issues affecting the UI shall be fixed by now

March 12th: adept 1.92 (rc)

• serious issues of beta 2 fixed
• only critical issues will be fixed from now on

March 30th: adept 2.0

• bar need for critical fixes arises, identical to 1.92

Comments

-Volker Löchte: Please also have a look at Xandros Networks, it has an excellent GUI

-Petr Rockai: There are few problems with the xandros ui -- too many scrollbars, eventual scalability problem with the treeview. The simple installer will surely take inspiration in this (as well as any other simple installers out there), still trying to improve on the ideas.