On Fri, May 23, 2014 at 02:12:08PM +0200, Jim Klimov wrote: > Package: apt-cacher > Version: 1.7.6 > Severity: important > > Dear Maintainer, > *** Please consider answering these questions, where appropriate *** > > * What led up to the situation? > > We are rolling out an Emdebian-based project in a LAN with weak internet > connectivity, so caching of packages is a substantial requirement for fast > redeployments of our test images. Apt-cacher was shown to be a pretty good > fit for our usecase, though with a nit...
<SNIP> > * What outcome did you expect instead? > > Accessibility of both local (direct) and internet (proxied and/or direct) > origin repository servers with a single configuration of apt-cacher. > It is my understanding that at the moment this separate approach is not > catered for. I believe a proper solution would be to add lists of backend > hosts that should or should not be accessed with an http_proxy, and it > should be valid to have a host listed in both lists (with both ways tried > in this case, if the first attempt over whichever transport fails). Thanks. Yes, I have thought before that the upstream proxy implementation was not as fine grained as it could be, but nobody has come with a case that warranted working on it. And I don't want to break existing installations. I think we could address this by optionally having the configuration option http_proxy be a list (similar to path_map) that is used to lookup request hostnames and return the upstream proxy to be used. No entry in the list for a direct request. Would that address your case? Best wishes Mark -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
