TransparentServicePackMaker

Differences between revisions 2 and 3
Revision 2 as of 2007-05-13 03:02:35
Size: 7046
Editor: dyn234073
Comment: Added link to work-in-progress implementation
Revision 3 as of 2007-06-24 22:09:53
Size: 6396
Editor: host81-156-45-60
Comment: Switched from Java to Python implementation. Clarified some explanation
Deletions are marked like this. Additions are marked like this.
Line 30: Line 30:
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). The tool will let users specify packages for the Service Pack to depend on (including meta-packages of other Service Packs, thus fulfilling Dan's use case) and easily allow users to create "update" service packs by including all of the packages installed on the system (default packages can be excluded by specifying a k/x/ed/ubuntu-minimal/desktop meta-package as a dependancy), along with any extra packages specified via a text box and collating them into a folder as an APT repository (Gemma's use case can be fulfilled by not ticking the box to make an update pack, and including her game and library packages via their paths for inclusion). A meta-package will then be created in the same directory level as the repository folder which depends on everything inside.
Line 32: Line 32:
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.
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 repository 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.
Line 40: Line 38:
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: http://www.freewebs.com/chriswarbo/Temporary/package-installer.tar.bz2
I (["Warbo"]) am working on a basic prototype of this tool, although help would be appreciated since my Python skills aren't too good. The GUI is usable although the tool only gets as far as parsing and downloading the required packages, it doesn't make the repository yet. A work-in-progress can be downloaded [http://www.freewebs.com/chriswarbo/Temporary/PackageInstaller.tar.bz2 here] (this depends on postpone, from [http://www.df7cb.de/projects/postpone/ here]).
Line 52: Line 48:
["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 :) ["Warbo"]: Please add any thoughts on the tool itself, ideas for overcoming the source issue or anything else :)

["Warbo"]: APT-on-CD is now incredibly similar to the Service Pack tool I am making... Perhaps adapting APT-on-CD would be a better course of action?

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.

Summary

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).

Rationale

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.

Scope

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.

Design

The tool will let users specify packages for the Service Pack to depend on (including meta-packages of other Service Packs, thus fulfilling Dan's use case) and easily allow users to create "update" service packs by including all of the packages installed on the system (default packages can be excluded by specifying a k/x/ed/ubuntu-minimal/desktop meta-package as a dependancy), along with any extra packages specified via a text box and collating them into a folder as an APT repository (Gemma's use case can be fulfilled by not ticking the box to make an update pack, and including her game and library packages via their paths for inclusion). A meta-package will then be created in the same directory level as the repository folder which depends on everything inside.

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 repository 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.

Implementation

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 since my Python skills aren't too good. The GUI is usable although the tool only gets as far as parsing and downloading the required packages, it doesn't make the repository yet. A work-in-progress can be downloaded [http://www.freewebs.com/chriswarbo/Temporary/PackageInstaller.tar.bz2 here] (this depends on postpone, from [http://www.df7cb.de/projects/postpone/ here]).

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 or anything else Smile :)

["Warbo"]: APT-on-CD is now incredibly similar to the Service Pack tool I am making... Perhaps adapting APT-on-CD would be a better course of action?


CategorySpec

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