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

[Shridhar Daithankar]

Hello,

On Tuesday 19 May 2009 18:44:13 Andrei Thorp wrote:
> We see people trying to make an Arch repo mirror to save themselves
> bandwidth. I think that doesn't really make too much sense. Instead,
> it seems much better to implement a download proxy. The way this works
> is that all traffic is routed through a computer which backs up stuff
> that passes through it. 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.

But no doubt http access will be dramatically fast :)

Not to mention, squid is only http caching proxy, not ftp.

> That seems like a great thing to use for Arch packages, as well as a
> lot of stuff really. Think about how much faster some websites and
> stuff can load if you already have all the common images downloaded to
> your LAN.

squid is great but I doubt it can help with multiple computers with arch. It 
can handle only download caching but thats not enough.

e.g. I have two arch boxes. The installations are not exactly identical. I am 
using shared network cache on nfs as detailed on arch wiki. How and when 
should I run "pacman  -Sc" to clean the repo?

There should be one way of supporting multiple computers that handles all the 
package scenario, including download, upgrade, deinstallation, clean up and 
rotation. +1 if it could handle identical and /or shared installations. (Yes I 
read about pkgdd but I need something thats in core/extra as it gives extra 
confidence in terms of testing.)

Arch is growing and it needs more meat :)
-- 
 Shridhar