From: Chris H. <ha...@de...> - 2004-01-26 08:55:32
|
On Wed, 2004-01-21 at 04:42, mi wrote: > Chris Halls wrote: > > If you are using an rsync backend, it is more efficient to rsync > > 'Packages', so it does that, and then uses gzip to make a Packages.gz t= o > > send to clients. > ok. It would be nicer though, to have no reminents. Not only a=20 > question of style. > I discovered some problems with relicts on standard office apps in the=20 > past. > At least, debugging becomes easier without them... Let me try again. You _need_ a 'Packages' file to rsync with the backend. You _need_ a 'Packages.gz' file to send to clients that request it. If you delete one of them you have to waste CPU recreating it later and apt-proxy becomes even slower than it already is. It's a CPU/disk space tradeoff and since this is supposed to be a package cache, you are more likely have a few MB disk space to spare than CPU cycles to waste. > > It's not a big problem - a Release file contains extra information abou= t > > a backend but is not essential. a-p cache's the fact that the Release > > file does not exist so it does not have to try the backend too > > frequently. > What backend do you mean ? Whichever backend you were talking about in the first place. > In debian main it says for my system: Great, now it is available. At the time the Release.fail was created, it was not reachable for whatever reason. > >>>If you're just starting out with apt-proxy, you might want to try the > >>>python rewrite, which is available from experimental and is much quick= er > >>>than v1. > I would like to. v1 seems to be significant slower than pure apt here.=20 > Approx. =F8 4 K instead of 5,5. > It's obvious when i download a large package. So it's probably not the=20 > rsync thing slowing it down ? You will get better throughput if you don't use the rsync protocol.=20 Actually, apt-proxy is the most efficient for large packages normally, since it just lets the slave program (wget or rsync) transfer the file from the internet to disk, and forwards it on to the clients. > But what's the difference. I use the same packet sources as before, of=20 > course. > However, i cannot install the recommended 'stat' package. You only need to worry about 'stat' on a plain woody system - it is part of later versions of the coreutils package. > >>I don't want to ditch woody/stable, hopefully a-p-2 runs under woody=20 > >>as well ? > > Oh, it needs twisted, which was not available in Woody, so no you can't > > use it I'm afraid. > I just have found and installed twisted 0.15.5-1 on a 3.0r1 CD. > It also installed the by now missing: > python-tk 2.1.3-3.2 > blt 2.4u-7 > blt-common 2.4u-7 > tix41 4.1.0.7-4.1 > Do you think this is sufficient to run ap2 ? I'm afraid twisted had too many bugs until about version 0.99, so you need to satisfy the dependency of twisted >=3D 1.0.0, which is very difficult on Woody. > And if so, where would i download it ? The same as all other experimental packages. You can find it by going to http://packages.debian.org/apt-proxy and choosing the experimental version. > I've no experience with cvs. I couldn't find any version 2.x -- or=20 > maybe it's still 1.x ? It is numbered 1.9.7 since 2.0 will be the first official stable release. > I found a tarball in a cvs branch. No version number. I think it=20 > wasn't the right one. > The config template is full of rsync. And the README says: > >> > Sat Dec 8 23:37:40 CET 2001 > Jan-Benedict Glaw <jb...@lu...> > << > He says he started ap2. I remember some people mentioned in the docs=20 > so far, > Rusty Russel, Manuel Estrada Sainz, Chris Halls. > But why isn't JB Glaw mentioned on the apt-proxy website ? That is not directly related to apt-proxy. He started a rewrite a long time ago but it did not get very far feature wise and I think he might have abandoned it. > I also became unsure about the official name. Is it 'apt-proxy' or=20 > 'ap2' or 'HEAD' ? It is version 2 of apt-proxy, which Manuel & I often abreviate to ap2.=20 It isn't in CVS HEAD at the moment - that is still version 1. > > ap2 does have upgrade scripts and should automatically update for you, > > but it needs more testing. > Does it change the cache structure ? No, you should be able to run the older and the newer version using the same cache. It adds some extra database files, but these are ignored by version 1. Chris |