<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://subsecret.dk/index.php?action=history&amp;feed=atom&amp;title=Package_management</id>
	<title>Package management - Revision history</title>
	<link rel="self" type="application/atom+xml" href="https://subsecret.dk/index.php?action=history&amp;feed=atom&amp;title=Package_management"/>
	<link rel="alternate" type="text/html" href="https://subsecret.dk/index.php?title=Package_management&amp;action=history"/>
	<updated>2026-05-04T03:29:12Z</updated>
	<subtitle>Revision history for this page on the wiki</subtitle>
	<generator>MediaWiki 1.45.3</generator>
	<entry>
		<id>https://subsecret.dk/index.php?title=Package_management&amp;diff=259&amp;oldid=prev</id>
		<title>Steffen Mikkelsen: Created page with &quot;=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 ar...&quot;</title>
		<link rel="alternate" type="text/html" href="https://subsecret.dk/index.php?title=Package_management&amp;diff=259&amp;oldid=prev"/>
		<updated>2013-06-22T14:37:55Z</updated>

		<summary type="html">&lt;p&gt;Created page with &amp;quot;=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 ar...&amp;quot;&lt;/p&gt;
&lt;p&gt;&lt;b&gt;New page&lt;/b&gt;&lt;/p&gt;&lt;div&gt;=Package management in Linux=&lt;br /&gt;
The package management in Linux is one of the areas where there is the biggest potential for improvement.&lt;br /&gt;
While the package management systems are generally well working, they have some fundamental limits that make them bad at their current job.&lt;br /&gt;
&lt;br /&gt;
*There is today WAY many more packages than when they were created. This gives many issues&lt;br /&gt;
**Downloading list of packages takes lot of bandwidth and time&lt;br /&gt;
**No easy way to browse through packages to find a needed tool. The exact name of the tool is required.&lt;br /&gt;
**Installing a package for more than one architecture (i386 and x64) requires lot of knowledge and guesswork.&lt;br /&gt;
**Only possible to install packages as a root user. Packages are stored in systems folder and not in users own home.&lt;br /&gt;
**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.&lt;br /&gt;
&lt;br /&gt;
However many of these things are actually solvable by breaking the package management system up into two.&lt;br /&gt;
&lt;br /&gt;
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)&lt;br /&gt;
*Updating system packages and server applications will anyway require root access, so no benefit of letting users install these.&lt;br /&gt;
*The number of packages will decrease to a tiny tiny fraction of the current amount. &lt;br /&gt;
**Easy to find what you are looking for, since there is only a short list of programs&lt;br /&gt;
**The package management system will be blazing fast.&lt;br /&gt;
**Chance of package dependency problems is low and testing is much easier&lt;br /&gt;
**Package maintainers are focused on a few important packages&lt;br /&gt;
&lt;br /&gt;
The new Graphical Package Mangement system will take a different approach to applications.&lt;br /&gt;
*Packages should generally be more static build and with fewer dependencies. Mainly only libraries from core systems.&lt;br /&gt;
*Applications can be installed system-wide (and some might even need to be) by root user.&lt;/div&gt;</summary>
		<author><name>Steffen Mikkelsen</name></author>
	</entry>
</feed>