KubuntuPackageManager

KubuntuPackageManager

Status

Introduction

Our current package manager, Kynaptic, is underdeveloped and misses a lot of features that other package managers have. We would like to develop Kapture (or rather its replacement as it is going through heavy redesign). It is another GUI package manager based on a new library, libapt-front, which is likely to also be adopted by Synaptic.

Rationale

Kynaptic is poorly written and unmaintained. Ept is under active development and offers a chance for a first rate package manager. The libapt-front library will allow for easy development of Apt based tools such as update notifiers or user friendly package installers along the lines of gnome-app-install. Currently these tools use python-apt and Synaptic as their interface to Apt.

Scope and Use Cases

When installing a package Boab wants to be able to easily search and browse the available packages. He wants to be able to control his apt sources graphically. Ept will let him do that.

Richard wants to write a user friendly installer for programmes. lipapt-front will let him do that easily. libapt-front has bindings to Python and Ruby so applications can be written in higher level languages.

Synaptic is also expected to be ported to libapt-front once complete so this Spec will help improve the whole of Ubuntu, not just Kubuntu.

Implementation Plan

libapt-front is currently in the middle of a major refactor (mostly done). First task is to complete this refactoring and create a powerful but easy to use Apt library. Language bindings for python will be created too (underway). Then a KDE frontend needs to be written (started), possibly reusing code from the current Kapture.

The frontend shall be implemented using a library for its widgets and utilities. This was used in the previous revision of Kapture and was of great benefit: the full frontend was written in about 400 lines of C++ and an updater wizard in some 200, the rest was shared in the common library (layered above a libapt-front predecessor).

This library will be based on the former libkapture and use libapt-front as a base. It should also serve as a way to validate and further improve the libapt-front API. It should make heavily use of debtags for package searching (debtags author enrico is involved with libapt-front as well).

The GUI of the application is to be designed. There should be an advanced user interface which uses best practice from Synaptic and other GUI package managers while making it easy to use the advanced search capabilities of debtags.

System updater should be provided as well, probably in form of a wizard that updates packages and offers upgradable packages to user for validation (in the advanced mode only maybe?) and then performs the upgrade.

Minimal goal for breezy is a working package manager and update tool using libapt-front.

Milestones

  • 19.8.2005 - EPT alpha release
    • Basic package management capabilities comparable to kynaptic (just a bit more robust): package listing and searching, apt-get update, upgrade, dist-upgrade, commit-based install and uninstall, purge; additionally, access to terminal is granted for dpkg and its child processes (unlike kynaptic), the right debconf frontend is used as well for the environment. Changes preview before commit, too.
  • 1.9.2005 - EPT beta candidate
    • Add features over kynaptic: undo/redo (before commit), sources.list editor, standalone updater.
  • 5.9.2005 - EPT beta release (and feature freeze)
    • Only critical fixes for bugs in candidate.
  • 27.9.2005 - EPT release candidate
    • Only bugfixes from beta.
  • 4.10.2005 - EPT stable release
    • Ideally same as candidate, if needed, critical fixes go in.

Notes

  • libapt-front will be linked statically during the development and in first stable EPT release
  • the libapt-front API is expected to stabilise by the end of the year with second EPT release; source compatibility will be guaranteed for a life of major libapt-front release from then on; binary compatibility will be guaranteed for patchlevel releases only
  • 3rd (major) EPT release is scheduled for "sometime next year"
  • minor (maintenance) releases will be made between major releases
  • by itself will be licensed under 3-clause BSD, but due to linking GPL code will be effectively covered by GPL

  • homepage: http://web.ekhis.org/adept.html

Progress Report

Aug 20th: There was a pre-alpha binary release on Aug 20th (slipped one day from planned alpha release), the real alpha will slip further -- i want to incorporate some of the feedback on pre-alpha) -- probably to 21st or 22nd of August. To accomodate for this, the gap between alpha and beta will be shortened somewhat. The Beta goals stand, with probably addition of debtags browsing/filtering support, as a replacement for the somewhat unwieldy sections that are used in kynaptic.

Aug 22nd: As i am writing this, the last set of adept alpha binaries is uploading. I will announce on my blog and wherever else i can, trying to get some testing coverage. I have slightly shifted plans again. The beta release is going to get a new ui, as feedback has shown that the package filtering is not consistent/easy enough. Well, the package list stays. Filtering will be redone though. libapt-front is maturing. The new debtags (the command line tool) and debtags-edit versions are both based on libapt-front. We have got some kick-ass integration on library level with libdebtags1. And more is coming. I will however consider slipping beta a week and having another alpha. That way, the gap between beta and release would shrink by the said week. However, the extensive unit testing done on libapt-front level seems to have brought its fruit -- adept shows rather good stability even in alpha release.

Sep 25th: Release Candidate is getting around. I am getting more positive than negative reports. The bug list is generally dominated by wishlists and minor problems. Still few things to fix for the RC, but we are getting there.

Packages Affected

kynaptic, debtags, synaptic

User Interface Requirements

Ept should be user friendly and include the best practice from other package managers.

Post stable-one things

There should also be an application focused GUI for less advanced users. This will be the KDE side of the package manager in FindingPackages. It should include a friendly user interface sorting packages in the same way as they are found in the k-menu/gnome-menu. The main part of the user interface should be a web browser and the package lists should show an icon, brief summery of function, user rating, popularity etc. The individual package page should include screenshots, reviews, extended descriptions. Searching should be easy to do and the web pages should support i18n. There should be the possibility of creating lists of applications suitable to paticular domains (e.g. my favourite apps, apps useful for teachers etc). The web pages should come from the Launchpad DOAP registry. Installing an application should be just a case of clicking the install button on the appropriate page. Clear indication should be given of the status of the install during download. The user interface should also include the updates manager. It should list all applications installed and include the ability to run the application, add the application to the desktop or panel and to remove the application.

The works need to be coordinated with the FindingPackages spec work that was bountied to Niran Babalola.

CategoryUdu CategorySpec

UbuntuDownUnder/BOFs/KubuntuPackageManager (last edited 2008-08-06 16:40:10 by localhost)