< SummerOfCode | 2007
An offline package update/installation facility for Pirut
- Student: DebarshiRay
- Mentor: SankarshanMukhopadhyay
- Documentation: http://fedoraproject.org/wiki/DebarshiRay/Opyum
- Project Page: https://fedorahosted.org/opyum
Abstract
I would like to develop an enhancement to Pirut that will enable users, who do not have the necessary bandwidth to download packages from the Internet, to install and update from packages downloaded on a different machine having better connectivity. This is inspired from one of last year's accepted proposals mentored by Ubuntu .
Detailed Description
Rationale
The problem with the current package management tools in Fedora is that they need a good and stable Internet connection for the user to derive maximum satisfaction. This has certain problems.
In many parts of the world, Internet connectivity is very costly commodity, which makes it impossible to use these tools in the conventional manner. It can be expensive to perform online updates on a set of machines which are not connected to each other by a private LAN, but have a common owner.
Therefore a mechanism is needed, which allows the user to download the required packages and its dependencies on a computer having the necessary facilities, and then create a 'yumpack' from which the installation or update can be performed on other systems.
Although this can be done using YUM, Wget, createrepo and Tar, those who are not conversant with RPMs, dependencies, etc. will find it difficult to do it this way. We need an easy way by which the user just indicates the packages that she wants to be there in the 'yumpack', and the tool gives her a single file which can be carried to the target installation. Installing or updating from the 'yumpack' should require a single click which would invoke Pirut to do the necessary task.
This not only addresses the problem of Internet connectivity, but also makes it very easy for ultra newbies to carry out installation or updates from custom 'yumpacks' made by more experienced people.
Use Cases
1. Manu has two machines-- one at work and one at home. The former has a nice Internet connection, while the other one does not. He is a not a geek, and wants to install a media player, which is there on his office box, at home. 1. Rakesh has five machines, which are not on the same LAN. Although all are connected to the Internet, the bandwidth is not good and it is costly to download the same updates and packages on all the machines individually. 1. My grandmother wants to try out Fedora. She does not know about computers, and finds it difficult to figure out what to install from the long list of available packages. So, I want to give her a 'yumpack' on a CD containing the packages she wants to have, so that she can just click and ask Pirut to install the contents of the pack, without thinking about anything else.
Possible Approach
A number of issues need to be addressed. Firstly there has to be a method to find out the installed package set on the target machine to avoid packing all the dependencies into the 'yumpack'. This can be done by having Pirut spit out the output of 'yum list installed' or 'rpm -qa' on the target machine in a file, which can then be used while creating the 'yumpack'. Only those dependencies that are missing will be added.
To make it easier when the profile is not available, a few inbuilt ones corresponding to the default installation of Fedora can be provided. The 'yumpack' creater can have the option to add her own custom profiles for the various target machines she has, which will be updated automatically every time a new pack is created. eg., if the target does not have Totem Media Player, then its profile would not have the entry for Totem's package. When a new 'yumpack' to install Totem is created, the name of the package is appended to the profile. This would reduce the need to repeatedly produce a installed package set of the target machine every time a pack has to be created.
Rollback should be easy since the existing package management tools are already expected to do it. In case the profile of the target machine was automatically updated while creating the pack, one should be able to rollback the changes in the profile too.
In case the 'yumpack' becomes too big to fit on a single CD the simplest solution that comes to my mind is to dump all the downloaded RPMs in a directory on the source machine and use 'createrepo' to generate the required meta-data. Once this is done, the RPMs and meta-data can be copied to multiple CDs in any order. On the target machine, everything is again dumped and re-arranged before starting the actual installation or update. This does waste some space while re-organizing the 'yumpack', but Pirut would have anyway cached the downloaded packages when directly installing from the Internet.
Future Expansion
Since both Pirut and YUM are written in Python, it should be possible to have an application that creates 'yumpacks' on Windows machines. This could be invaluable for people whose only access to the Internet is through cyber cafes running Windows on their machines.
Profit for Fedora
The ability to use 'yumpacks' will make Fedora more appealing to those who lack cheap and good Internet bandwidth, and know very little to manually create their own packs.
One of the main reasons for people to chose Fedora over some other distribution (read Ubuntu) is the fact that a large number of applications are already present on the DVD or CDs, reducing the need for downloading packages from the remote repositories. I plan to further this advantage through this proposal.
Roadmap
1. 1. Discuss the idea with the Fedora community (till early April) 1. Get myself more familiar with the internals of YUM and Pirut (till mid April). 1. Brush up Py-Gtk+, which would be required to create the tool (till late April). 1. 1. Identify the basic requirements for creating 'yumpacks',installing from them and managing profiles (by mid May). 1. Create a rough CLI implementation in Python to create and install from 'yumpacks' (by late May). 1. Add the ability to manage profiles and generate a list of installed packages in the target machine (by early June). 1. 1. Identify the elements necessary for making a GUI application (by early June). 1. Add the GUI portions to the above tool to create the first prototype (by mid June). 1. 1. Make Pirut handle 'yumpacks' (by late June). 1. Make Pirut handle 'profiles' (by early July). 1. Polish the interface to adhere to some basic HIG (by mid July). 1. Test the features and take feedback from potential end-users (late July). 1. 1. Write the associated documentation (by late July). 1. Do any packaging that might be necessary (by early August).
Current Status
With the release of version 0.0.2 all the above features, except installation from YumPacks, have been implemented and functional. It has been decided to use system-install-packages to install from a YumPack. This would need some changes in the existing system-install-packages to make it recognize and handle YumPacks inherently.
Since a YumPack is basically an uncompressed Tar archive, for the time-being one can extract all the contents of a YumPack and then use the existing system-install-packages to install all of them.
Biography
I am a 22-year old student based in the city of Kolkata (formerly Calcutta), which is located in the state of West Bengal in eastern India.
I have been using Fedora for two years. Having spent most of this time on low bandwidth networks, where people consider themselves blessed if they get 15kbps continuously, I have been at the receiving end of this problem for quite a long time. Now that my college life is drawing to an end, all that I shall have is an even thinner dial-up connection where high cost and low bandwidth will make it extremely difficult to keep my system updated or install new things. Thus I am very enthusiastic about this proposal, because it can be the crucial factor for letting me enjoy my operating system.