Re: [ITR] templates://apt-cacher-ng/{apt-cacher-ng.templates}

[Eduard Bloch <edi@gmx.de>]

#include <hallo.h>
* Justin B Rye [Fri, Jul 31 2009, 11:41:48PM]:
> > _Description: Preconfigure apt-cacher-ng for transparent requests source rerouting?
> 
> "Transparent requests source rerouting" is hard to make any sense
> out of, and reading the documentation doesn't help, since it doesn't
> use this term "rerouting" at all.  Instead, anything more complex
> than plain proxying (which you've told us isn't what you mean here)
> is referred to in the docs as "URL remapping".  Could you use the
> same terminology here?

I could. But would a user understand it without reading the introduction
of the particular chapter in the docs? I doubt that. And if not, please
suggest terminology that might be understood quickly in a debconf
message and does not need another large paragraph.

>   _Description: Configure apt-cacher-ng to use URL remapping?
> 
> >  Apt-cacher-ng can request packages from a mirror of your choosing, instead of
> >  the one requested by the client. One possible use of this feature is quick
> >  changing of the real download mirror for all users without modifying every
> >  single client system. To configure it, sets of source mirrors need to be
> >  configured for various distributions.
> 
> That's promising, but then ends up unclear.  I need to configure
> source mirrors for... "various distributions"?  Maybe you mean:
> 
>    single client system. To configure it, a set of URL remappings
>    needs to be set up for each APT source.

Not at all. I see that "the apt source" is popular terminology among
users but it's just not correct here. I.e. you can configure multiple
APT sources, for different releases, for different package types
(binary/source), for different parts of the repo, but they all could
still refer to copies of the same origin, full or partial.

> (An example might help.)

Examples tend to be long. Much longer than a sane debconf message
should include, IMHO.

> >  During the package installation, this sets can be prepared based on the
> >  current state of /etc/apt/sources.list. Optionally, this process can be
> >  repeated on every package update (modifying configuration files later).
> 
> I think I understand most of this, except for the last parenthesised
> section which I'll have to guess at.  Is it: 
> 
>    These sets can be prepared now, based on the current state of
>    /etc/apt/sources.list. Optionally, this process can be repeated on
>    every package update (modifying the configuration files each time).

Ok.

> >  NOTE: selecting "No automated setup" can leave previously created mirror
> >  configuration behind, which needs to be updated by cache administrator manually.
> 
>   If you select "No automated setup", any updates to an existing
>   configuration will need to be performed manually.

First, isn't addressing the user directly is a bad style and should be
avoided where possible?
Second, it should be mentioned that something is already there. Some
users where bitching about old configuration left there and not kept
uptodate anymore.

> In the control file, you've just reverted to the original.  Instead

Not exactly the original but a state in-between. I lost the changes
applied after your last suggestions.

>   Description: caching proxy for APT sources         
>    Apt-Cacher NG is yet another implementation of an HTTP proxy for
>    Debian-style software repositories.

It can do RPM so why should I not mention it?

Anyhow, all this "yet another...does the same" tone is lame, I rewrote
it now using your changes to a new version.

_Description: Preconfigure apt-cacher-ng for transparent requests source rerouting?
 Apt-cacher-ng can request packages from a mirror of your choosing, instead of
 the one requested by the client. One possible use of this feature is quick
 changing of the real download mirror for all users without modifying every
 single client system.
 .
 To configure it, sets of source mirrors need to be
 configured for various distributions. These sets can be prepared now, based on
 the current state of /etc/apt/sources.list. Optionally, this process can be
 repeated on every package update (modifying the configuration files each
 time).
 .
 NOTE: selecting "No automated setup" can leave previously created mirror
 configuration behind, which needs to be updated by cache administrator
 manually.

Description: Caching proxy for distribution of software packages
 Apt-Cacher NG is yet another implementation of a HTTP proxy for
 software packages, primarily targeted at Debian/Ubuntu packages but
 may also be used with others types.
 .
 It follows similar principles as other package caching proxies (Apt-Cacher,
 Apt-Proxy, Approx): a central machine presents a special HTTP
 proxy for the local network, and clients configure their APT setup
 to download through it. Apt-Cacher keeps a copy of all useful data
 that has been passed through it and when a similar request appears,
 the old copy of the data is delivered without redownloading it from
 the distribution mirrors.
 .
 Apt-Cacher NG was developed as a redesign of Apt-Cacher with focus on
 maximizing throughput with low requirements on system resources and external
 packages.