SmartPackageManager

Differences between revisions 2 and 25 (spanning 23 versions)
⇤ ← Revision 2 as of 2005-10-31 23:16:58 →
Size: 733
Editor: 187_220_103_66-WIFI_HOTSPOTS
Comment: link fixed
← Revision 25 as of 2008-08-06 16:29:27 → ⇥
Size: 5127
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
 * '''Created''': [[Date(2005-10-31T22:52:04Z)]] by MichaelVogt
 * '''Contributors''': MichaelVogt
 * '''Packages affected''': 		 * '''Created''': <<Date(2005-10-31T22:52:04Z)>> by MichaelVogt
 * '''Contributors''': MichaelVogt, ColinWatson, JeffWaugh
 * '''Packages affected''': smartpm, apt
Line 10: Line 10:
There is a new package managment system availabe written by GustavoNiemeyer called "smart". It is able to deal with debs, rpm, slackware tgz (at the same time). We should consider using it in ubuntu and figure what features (if any) are missing. There is a new package management system available written by GustavoNiemeyer called "smart". It is able to deal with debs, RPM, slackware tgz (at the same time). We should consider using it in Ubuntu and figure out what features (if any) are missing.
Line 14: Line 14:
Smart has a very clean architecture and is used by many other distributions already. It has the potential to become the de-facto standard as a package manager.
Line 15: Line 17:

 1. Bob upgrades his distribution and is confused because apt makes bad decisions on the upgrade. When he tries smart it is doing better.
 1. Fred wants to hack on a package-managment application. He is frustrated by the libapt interface.
Line 18: Line 23:
We need to evaluate how to make a migration from apt to smart possible and painless and what features/changes are required to make smart the first-class package manager for Ubuntu.
Line 19: Line 26:

For edgy we will make it easier for people to use smart and encourage its usage. We will also start to add features to it that are currently missing but that are important for ubuntu.

We will create a launchpad "smart testing" team that encourages the usage and testing of smart in ubuntu.

To make the transition easier we will create a plugin for smart that will dynamically update smarts channel list based on the /etc/apt/sources.list.

The gpg key handling needs to be improve in smart to match the current behaviour in apt. We should also do a automatic initial import of the apt-keys into smarts key list (or just share the same keyring). See http://lists.labix.org/pipermail/smart-labix.org/2006-June/001055.html for details.

The current Gtk UI needs HIG love and improve it in general. We may consider to model it after the synaptic glade file to make the transition for the users easier.

The package needs to be split into a smart package and a smart-gtk package to make it feasible for server installs.

We need to evaluate the time/memory consumption of smart in a clean chroot for upgrade/complex installs and see how it compares with apt. Memory usage is a big issue on the desktop and alternate install CDs.
Line 22: Line 43:
=== Code === The recently released smart 0.42 support automatic syncing its channels with the /etc/apt/sources.list information. Some initial work on automatic dependency removal was started (http://lists.labix.org/pipermail/smart-labix.org/2006-June/001199.html).
Line 24: Line 45:
=== Data preservation and migration === The smartpm testing team was created: https://launchpad.net/people/smartpm-testing
Line 28: Line 49:
== BoF agenda and discussion == There are more issues that need to be adressed to make smart a first-class alternative package manager in ubuntu. It is unlikely that those can be adressed in the edgy timeframe. Among those:

 * Qt frontend (to make Riddell happy :) - this requires it to be possible to access the konsole terminal widget from pyqt which is not possible right now (because some package still like to do stuff in the terminal like prompting etc)
 * established tools like apt-listchanges/apt-listbugs/debconf need to continue working so a mechanism like apts SPkg::{Pre,Post}-Install-Pkgs hook is required.

 * port the various tools (gdebi, update-manager, gnome-app-install, update-notifier, unattended-upgrades) to smart. This could be done by providing a compatibility layer for python-apt. I have created a specification for porting these tools to smart at https://wiki.ubuntu.com/GnomeSmartInterfaceSpec --dfarning

 * change the software-properties channel editor to edit channels in a nicer way (the smart buildin channel dialog is too technical)
 * switch /etc/cron.daily/apt to smart (and provide the same features)

 * the installer makes heavy use of apt-get/aptitude, we need to identify what it needs and make sure that smart provides similar features
 * progress information on installing/fetching via a fd needs to be supported for the installer
 * dist-upgrade where the python version changes may become a issue, we need to check this (should be easier given PythonRoadmap and python-central)

 * tracking and auto-removal of unused dependencies (just like aptitude)
 * use that in gnome-app-install to be able to automatically remove the dependencies that were installed for a given application
 * use the "automatically-installed" info in smarts problemResolver (consider non-automatic packages more important during conflict resolution)
 * support for "deb-src" type URIs (still required with the NoMoreSourcePackages spec?)
 * support for translated package descriptions (similar to apts DDTP format)
 * support for tasks
 * support "NotAutomatic" flag in the Release file (e.g. for experimental)
 * this spec might have been obsoleted by [[DesktopTeam/Specs/PackageKit]] -- AzraelNightwalker <<DateTime(2008-02-26T12:15:10Z)>>

----

Summary

There is a new package management system available written by GustavoNiemeyer called "smart". It is able to deal with debs, RPM, slackware tgz (at the same time). We should consider using it in Ubuntu and figure out what features (if any) are missing.

Rationale

Smart has a very clean architecture and is used by many other distributions already. It has the potential to become the de-facto standard as a package manager.

Use cases

  1. Bob upgrades his distribution and is confused because apt makes bad decisions on the upgrade. When he tries smart it is doing better.
  2. Fred wants to hack on a package-managment application. He is frustrated by the libapt interface.

Scope

We need to evaluate how to make a migration from apt to smart possible and painless and what features/changes are required to make smart the first-class package manager for Ubuntu.

Design

For edgy we will make it easier for people to use smart and encourage its usage. We will also start to add features to it that are currently missing but that are important for ubuntu.

We will create a launchpad "smart testing" team that encourages the usage and testing of smart in ubuntu.

To make the transition easier we will create a plugin for smart that will dynamically update smarts channel list based on the /etc/apt/sources.list.

The gpg key handling needs to be improve in smart to match the current behaviour in apt. We should also do a automatic initial import of the apt-keys into smarts key list (or just share the same keyring). See http://lists.labix.org/pipermail/smart-labix.org/2006-June/001055.html for details.

The current Gtk UI needs HIG love and improve it in general. We may consider to model it after the synaptic glade file to make the transition for the users easier.

The package needs to be split into a smart package and a smart-gtk package to make it feasible for server installs.

We need to evaluate the time/memory consumption of smart in a clean chroot for upgrade/complex installs and see how it compares with apt. Memory usage is a big issue on the desktop and alternate install CDs.

Implementation

The recently released smart 0.42 support automatic syncing its channels with the /etc/apt/sources.list information. Some initial work on automatic dependency removal was started (http://lists.labix.org/pipermail/smart-labix.org/2006-June/001199.html).

The smartpm testing team was created: https://launchpad.net/people/smartpm-testing

Outstanding issues

There are more issues that need to be adressed to make smart a first-class alternative package manager in ubuntu. It is unlikely that those can be adressed in the edgy timeframe. Among those:

  • Qt frontend (to make Riddell happy Smile :) - this requires it to be possible to access the konsole terminal widget from pyqt which is not possible right now (because some package still like to do stuff in the terminal like prompting etc)

  • established tools like apt-listchanges/apt-listbugs/debconf need to continue working so a mechanism like apts SPkg::{Pre,Post}-Install-Pkgs hook is required.

  • port the various tools (gdebi, update-manager, gnome-app-install, update-notifier, unattended-upgrades) to smart. This could be done by providing a compatibility layer for python-apt. I have created a specification for porting these tools to smart at https://wiki.ubuntu.com/GnomeSmartInterfaceSpec --dfarning

  • change the software-properties channel editor to edit channels in a nicer way (the smart buildin channel dialog is too technical)
  • switch /etc/cron.daily/apt to smart (and provide the same features)
  • the installer makes heavy use of apt-get/aptitude, we need to identify what it needs and make sure that smart provides similar features
  • progress information on installing/fetching via a fd needs to be supported for the installer

  • dist-upgrade where the python version changes may become a issue, we need to check this (should be easier given PythonRoadmap and python-central)

  • tracking and auto-removal of unused dependencies (just like aptitude)
  • use that in gnome-app-install to be able to automatically remove the dependencies that were installed for a given application
  • use the "automatically-installed" info in smarts problemResolver (consider non-automatic packages more important during conflict resolution)

  • support for "deb-src" type URIs (still required with the NoMoreSourcePackages spec?)

  • support for translated package descriptions (similar to apts DDTP format)
  • support for tasks

  • support "NotAutomatic" flag in the Release file (e.g. for experimental)

  • this spec might have been obsoleted by DesktopTeam/Specs/PackageKit -- AzraelNightwalker 2008-02-26 12:15:10

SmartPackageManager (last edited 2008-08-06 16:29:27 by localhost)