Switched from Java to Python implementation. Clarified some explanation
Updated link to latest code
|Deletions are marked like this.||Additions are marked like this.|
|Line 38:||Line 38:|
|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]).||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/TransparentServicePackMaker.tar.bz2 here] (this depends on postpone, from [http://www.df7cb.de/projects/postpone/ here]).|
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.
Launchpad Entry: transparent-service-pack-maker
Packages affected: New package
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.
* 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 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.
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/TransparentServicePackMaker.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).
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
["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?