[arch-general] Building local repo - eliminating dups - why some new x86_64?

[Eric Bélanger]

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
>>> Internet.
>>
>> 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
>> too.
>
> 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.
>>
>> (snip)
>>
>
> Yeah, some decent ideas there.
>
> -AT
>

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.