#include <hallo.h> * Stuart Pook [Wed, Mar 25 2009, 09:14:31AM]: > On 25/03/09 00:15, Eduard Bloch wrote: > >> hostname and as last resort it assumes that "debrep" itself is the >> hostname. > > This is the source of the confusion I think. I certainly didn't > understand the error concerning "debrep". Is there any situation where > "debrep" would be the correct hostname to use? I think not. If the
Why not? It's a valid local hostname, or something you might put into /etc/hosts. Actually, the source of confusion is the simplicity of the cache structure and workarounds for THE HUMAN FACTOR. In the expiration/import tasks, it's needed to find a working URL to update index files. This can be done from the X-Original-Source keys stored internally... but what, if the administrator changed the config and the URL is no longer resolvable? Or if the URL is damaged or just missing (imported contents)? Ok, then we go by the repository name and try to map the thing to some set of backend descriptors. But what, if there are none, i.e. removed by administrator in the meantime? -> BOOM. No straight-forward way to solve the problem. It's easy to make assumptions of others' code only for somebody not having an eye on all possible configurations and corner cases. > internal cache-to-weblocation resolver cannot find a hostname then it > should stop with an error message explaining the problem. This would > be a lot clearer than continuing and give a strange error message > about debrep" not being found. I can improve the message and documentation (I just did locally). >> To check if the assumption is true, please run $ find >> /var/cache/apt-cacher-ng/debrep/dists/ -name '*Packages.bz2.head' | >> xargs grep X-Orig | cut -f2 -d' ' >> and probably there are some invalid URLs (without hostname) in that >> list. > > :; find /var/cache/apt-cacher-ng/debrep/dists/ -name '*Packages.bz2.head' | > xargs grep X-Orig | cut -f2 -d' ' > http://ftp.fr.debian.org//debian/dists/squeeze/main/binary-i386/Packages.bz2 Ok. I guess they have been auto-repaired in the meantime. > let me try again > > : root; > /etc/apt-cacher-ng/backends_debian > : root; dpkg-reconfigure apt-cacher-ng > Stopping apt-cacher-ng: apt-cacher-ng. > Starting apt-cacher-ng: apt-cacher-ng. > : root; grep fr.deb /etc/apt-cacher-ng/backends_debian Weird. Ok, what does $ sh -x /var/lib/dpkg/info/apt-cacher-ng.postinst configure tell you? > : root; ls -l /etc/apt-cacher-ng/backends_debian > -rw-r--r-- 1 root root 0 2009-03-25 09:11 /etc/apt-cacher-ng/backends_debian > >> Okay... I changed the code for the next release to print the name from >> the failed lookup immediately, this should make the problem >> identification easier. > > As explained above, I would prefer another solution. Me too. Ideally, the user should never drop the backends definitions after using them for a while. Regards, Eduard. -- * kowallke hat garde DIE lebensweisheit erfunden: don't cry. Just die! <frobnic> nicht quaseln. machen. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
