[arch-general] Building local repo - eliminating dups - why some new x86_64?
snowmaniscool at gmail.com
Tue May 19 15:46:13 EDT 2009
On Tue, May 19, 2009 at 2:03 PM, Andrei Thorp <garoth at gmail.com> wrote:
>>> (...) When a computer on the network asks for a file
>>> that's been downloaded previously, there is no need to go into the
>> Yes and no.
>> arch packages are not exactly small. I run a squid cache and a cache object
>> size of 128KB serves me pretty well. To accomodate all arch packages, this
>> setting has to go up to may be 150MB(for openoffice). If the cache start
>> caching every object of size upto 150MB, it won't be as effective or will
>> baloon dramatically. Not to mention the memory requirement that will go up
> I'm under the impression that you can configure it in other ways and
> not just space, therefore letting it work for Arch packages (say, from
> your favourite mirrors) and not from everywhere. Yeah, it does
> increase the requirements, but I'm sure it's handleable.
>> But no doubt http access will be dramatically fast :)
>> Not to mention, squid is only http caching proxy, not ftp.
> "Squid is a caching proxy for the Web supporting HTTP, HTTPS, FTP, and
> more." -- their website.
>> squid is great but I doubt it can help with multiple computers with arch. It
>> can handle only download caching but thats not enough.
> Yeah, some decent ideas there.
Another solution is to have all computers using only one pacman cache
located on a single computer via nfs. So once a computer has
downloaded a packages, all the other ones can grab it directly from
the local network.
If you have i686 and x86_64 computers, pacman can't differentiate
between the two arches if the packages name doen't contain the arch
(old pkg and community pkg). It reports a md5sum mismatch. You just
need to say 'yes' to redownload the package when that happen. If you
want to get rid of that problem, setup two caches: one for each arch.
More information about the arch-general