Differences between revisions 1 and 2
Revision 1 as of 2007-05-11 14:42:08
Size: 7000
Editor: dyn233056
Comment: Initial creation
Revision 2 as of 2007-05-13 03:02:35
Size: 7046
Editor: dyn234073
Comment: Added link to work-in-progress implementation
Deletions are marked like this. Additions are marked like this.
Line 42: Line 42:
(Link to current prototype will be put here shortly, once it is uploaded somewhere) Here is a link to the current, non-working Java prototype:

Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.


This spec covers the creation of an easy to use tool to create service packs (collections of updates, new programs, etc.) which require nothing more than the current APT system to install (hence "transparent", since the packs are treated as regular packages).


It is often useful to install a defined set of packages on a system, or multiple systems, with or without Internet access. The idea of letting users and developers create Service Packs (UbuntuServicePacks for example), large collections of software installations/updates, addresses this, but current proposals for implementing such a system (like OfflineUpdateSpec) are limited due to the reliance on a service pack installation tool. Allowing service packs to be installed with nothing more than the regular APT system (using tools like Gdebi) would instantly make such packs available for all Ubuntu (or Debian-based) users, and potentially other distros, without creating yet another application installation format/method.

Use Cases

* John has installed Ubuntu on 50 isolated machines for his employees, however the software installed by default is not ideal for their jobs. John creates a service pack called "work-applications" which contains all of the extra programs needed by his employees, then installs it onto each system by double clicking the created Debian package to launch Gdebi.

* Lynn's mother wants to keep in contact with her daughter when she moves away, so Lynn installs Ubuntu for her and sets up email and instant messaging applications. Lynn's mother doesn't understand the updates or installation tools, so Lynn posts her occasional service packs on CD containing all of the security and speed updates Lynn's mother could do with, without any extra programs or features which would confuse her.

* Dan works in a professional multimedia company and needs to install certain specialist applications on his workforce's Ubuntu computers. Due to the size of these programs, and the differing needs of his team, he makes different service packs called "graphical-tools" "audio-tools" and "video-tools" which all rely on the service pack "standard-setup", thus everyone gets the standard tools, each gets their own specialist tools, and no space is wasted with unneccessary programs installed or bloated service packs.

* Gemma has made a game and wants to package it for Ubuntu. The game depends on some obscure libraries, and some non-standard but widely used libraries. She puts packages of all of these libraries, along with her game, into a service pack so users installing it will definetly have all of the required libraries, however any newer versions of the widespread libraries already installed will not get overwritten by those in the pack.


A new tool will be developed which allows easy creation of service packs. For the service packs to be seen as an APT source there may need to be some work done on adding temporary sources.


The tool will easily allow users to create "update" service packs by including all of the non-default (ie. not installed through k/x/ed/ubuntu-minimal/desktop meta-packages) packages installed (refetching them if needed, taking from /var/chache/apt/archives if not), along with any extra packages specified via a text box and collating them into a folder as an APT repository (if the user does not tick the include non-default packages box then only these 'extra' packages will be included). A meta-package will then be created in the same directory level as the repository folder which depends on everything inside. A ".hidden" file may also be created to hide the folder, thus leaving only the meta-package visible (however, users may think that the meta-package is the entire pack and thus move/copy it without its accompanying repository. This could be solved by distributing the folder and meta-package in an archive, or else just do away with the .hidden file altogether. This decision needs discussion).

When a user double clicks the meta-package the Gdebi tool appears and allows them to install the pack just like any other package, although any packages not currently installed or available as a newer version in a current repository are taken from the included reopsitory folder. If the service pack meta-package is removed then so is any additional software it installed (the standard behaviour for tools like aptitude, which I think is now in apt-get and anyway is beyond the scope of this spec). If any software in the pack is removed then so is the pack.

An "Advanced" tab in the creation tool allows users to specify exact versions for the included packages if they want to, as well as any service pack dependencies (to let Dan's "video-tools" require the "standard-setup" pack). These dependencies just add the meta-package of the pack being depended on as a dependency of the new pack's meta-package, thus the existing system does not need modifying.


The tool should probably be made in Python with GTK/QT frontends, since the tool will only be run occasionally, and never as a daemon, thus Python's interpreted nature won't cause any system slowdown.

I (["Warbo"]) am working on a basic prototype of this tool, although help would be appreciated and also it is made in Java, since I am not particularly good in Python yet. The GUI is usable (although the "Advanced" settings will be accessed [when implemented] via a button, as the RAD tool used did not handle tabs well), although the file reading (for dependencies) and writing (to make the packs and packages) need to be implemented correctly.

Here is a link to the current, non-working Java prototype:

The current plan, until the APT source adding issue is resolved, is to create 2 packages, the first of which has no dependencies and adds a file to sources.list.d and the second of which, the main meta-package, removes this after installation (and possibly conflicts with the first package, thus causing its removal).

Outstanding Issues

The way to add APT sources should be addressed. The point of the tool is for easy, (apparently) one-file installation of large software collections, however this one file will not install without APT using its accompanying repository as a source, yet the system cannot be changed (to add the source) without installing something (hence the current solution above).

BoF agenda and discussion

["Warbo"]: Please add any thoughts on the tool itself, ideas for overcoming the source issue, whether using a .hidden file would be a good idea or anything else Smile :)


TransparentServicePackMaker (last edited 2008-08-06 16:25:14 by localhost)