Package Manager A B tech final year project

 
Package Manager for Source Code Installation
Project Description
Our goal is to introduce a Package Manager for Source Code Installation in Linux distributions. This Package Manager would itself take care of maintenance of complete system, which so far has been a very cumbersome job for any administrator. This LPM along with a Registry would provide an alternative back-end for various text configuration files.
Thus, instead of each application having its own text-configuration files, our application provides a universal, hierarchical, fast & consistent namespace & infrastructure to access configuration parameters through a key-value pair mechanism.
This would include creation of separate entities:-

•     local database for local machine administration & maintenance.
•     registry for local as well as remote administration of the machine configuration.

Architecture

•     I386 Architecture Machines.
•     Red Hat Linux 9.0 Operating System.

1.3 Project Requirements
The project has some hardware & software requirements that are described as follows:-
1.3.1 Software Requirements

•     Red Hat Linux 9.0 with kernel(2.4.23)
•     Linux GUI builder package – QT
•     A C/C++ IDE for Linux – Anjuta
•     Elektra API’s

1.3.2 Hardware Requirements

•     Two PC’s with usual configurations (128/256RAM P4 Processors etc.)
•     LAN connection b/w the machines.

1.4 The Problem
It has been long desired to have some kind of Package Management system in existing Linux environment. Due to the pre-existing feature of being Open Source, any package can be installed & used, almost anywhere in a Linux system (be it Personal/Server configuration).
Today’s GNU/Linux systems are a sum of independent components collected from Open Source Community. Each of them already has a working, but selfish configuration system.
1.5 A Basic Scenario
One of the system (maintained by an administrator X) has an Apache package (say version 1.4) installed from source (instead of RPM distribution).After some time a new administrator (say Y) starts maintaining that system. Suppose he comes to know that Apache (version 1.4) has a serious security flaw and he installs a newer version (2.0). Now to clean the system more efficiently he has to effectively delete all the files (main files as well as support files) from various locations which become a very tedious task itself.
Thus we realize that the overall maintenance of complete Linux system is a highly cumbersome process which any administrator has difficulty in carrying out, both efficiently & effectively.
1.6 How the problem has been attacked
Now that the problem at hand is very much clear, the next & foremost step is as to how the information about various packages, getting installed on the system, needs to be track down & stored. One of the most important design issues that needs utmost attention is:-
The existing system should not change. It means that we cannot go about changing the entire installation methodology, just for the sake of obtaining the desired information. The reason is if the existing system changes, there is a high probability that the newer system is not at all welcomed by the existing developer & user society.
Thus after considering various other issues, the solution that has been finalized is as follows:-
We need to trap the information when & where it is getting created & moved into the existing system.
This information then has to be stored & later on retrieved in an efficient & effective way that would suite our project requirements.
Thus the complete project now gets divided into 4 different stages. They are:-

•     Collection of all the data.
•     Extraction of Information.
•     Efficient storage of the information.
•     Effective retrieval of this information.