Package management in Linux
The package management in Linux is one of the areas where there is the biggest potential for improvement. While the package management systems are generally well working, they have some fundamental limits that make them bad at their current job.
- There is today WAY many more packages than when they were created. This gives many issues
- Downloading list of packages takes lot of bandwidth and time
- No easy way to browse through packages to find a needed tool. The exact name of the tool is required.
- Installing a package for more than one architecture (i386 and x64) requires lot of knowledge and guesswork.
- Only possible to install packages as a root user. Packages are stored in systems folder and not in users own home.
- Large chance that some packages will conflict and cannot be installed together. Impossible for maintainers to test all combinations of packages with the current amount.
However many of these things are actually solvable by breaking the package management system up into two.
The current package management system is kept for the Core System and for Server applications (server applications has it own repository, so it is only used for servers by default)
- Updating system packages and server applications will anyway require root access, so no benefit of letting users install these.
- The number of packages will decrease to a tiny tiny fraction of the current amount.
- Easy to find what you are looking for, since there is only a short list of programs
- The package management system will be blazing fast.
- Chance of package dependency problems is low and testing is much easier
- Package maintainers are focused on a few important packages
The new Graphical Package Mangement system will take a different approach to applications.
- Packages should generally be more static build and with fewer dependencies. Mainly only libraries from core systems.
- Applications can be installed system-wide (and some might even need to be) by root user.