[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Package cache



#include <hallo.h>
* Gonsolo [Sat, Aug 18 2007, 07:29:55PM]:
> Hi!
> 
> Would it be feasible to add something like a package cache to Debian?

What you describe is not a cache and even less a _package_ cache.

> This way only a minimal Debian system would be installed locally on
> the hard disk. All other packages are fetched only when used. For example,

Usualy the packages are not used (ie. not accessible) when they are not
installed. So you require the packages to be installed but then the
files be removed, and only restored (from the original package contents)
on access?

> user Joe sets his package cache to 400MB and installs Openoffice.
> The installation lasts one second because only a few symlinks are created.

Symlinks to what?

> When Joe uses Openoffice for the first time, All necessary files are fetched
> >from the Internet and put in the package cache. So the first startup will be
> slow. The next time all necessary files are on the disk and Openoffice starts
> as usual.

If you want to keep the files aside but ie.
compressed than you should use a compressing filesystem.
But if you want something working on access, expect it to perform very bad. 
Ie. if you want to install the files from original package files on
access, then you need some daemon that fetches them, you need a
kernel-based add-on to interrupt the file IO when the application
touches the file (everything including stat, not just reading), and you
need to make sure that your network is always in perfect state.

IMHO those are just too many unsafe requirements that make the whole
approach insane on this level of an operating system.

Another idea would be the substitution of big monster packages just with
a dummy package containing menu entries (and desktop files) that engage
some eye-candy-enabled command for
"apt-get install monsterpackage && /usr/bin/monstertool" .

However, such dummy packages would not be sufficient to act as real
drop-in replacements (ie. have the same package names) because that may
break other packages that depend on the contents (actuall files) of big
packages.

> The package cache is managed with a last-recently-used (LRU) strategy.
> So all the packages Joe normally uses are in the cache. When the cache
> overflow a package is deleted on the disk. Joe can "pin" some packages
> into the cache to avoid statup slowdown.

There is too much risk to break the system when doing this without sane
control, and your proposal does not sound convincing. At least the
package with 

> With a package cache a normal Debian installation would not be hundreds
> of megabytes of gigabytes after a few months/years of usage (package
> installation) but only 400MB and Joe doesn't have to manually remove
> packages when his hard disk is full.

Then uninstall them. I do not like the current situation either and I
considered to write an atime tracker which could keep statistics to be
analyzed daily in order to give the users advices to uninstall certain
packages and give the maintainers advices to split or merge other
packages.

Kind of popcon but placed a bit deeper in the system.

Eduard.

-- 
<Rhonda> Hah! Ich hab das Monster php gebändigt!
* Joey . o O ( Rhonda is now known as Siegfried )



Reply to: