Re: [ITR] templates://apt-cacher-ng/{apt-cacher-ng.templates}
#include <hallo.h>
* Justin B Rye [Sat, Aug 01 2009, 08:17:06PM]:
> Eduard Bloch wrote:
> >>> _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.
>
> This is just the short description. Novice users probaby have
> little hope of understanding it on its own; but if you use the
> established terminology, there's a chance the people who have read
> the docs might recognise it. The trouble with "rerouting" is that
> it sounds as if you're talking about the route that packets take to
> reach a given Debian mirror. In fact the phrase "transparent
> requests source rerouting" is hard even to parse. Is it
Ok, that's enough. Let's strip all the extra terminology and describe
what it actually does. See below.
> > (binary/source), for different parts of the repo, but they all could
> > still refer to copies of the same origin, full or partial.
>
> So you specifically mean origins? This is gradually getting
Why do you mean by saying "origin"?
> clearer. Should the line about "various distributions" have said
> something like this?
>
> single client system. To configure it, a set of URL remappings
> needs to be set up for each APT origin.
Ugh, this confuses even me. What is an "APT origin"? Something you got
APT from?
> > Examples tend to be long. Much longer than a sane debconf message
> > should include, IMHO.
>
> If you can't find a way of phrasing this debconf template that will
> fit in the space available, you could always put it in a README and
> tell users to read that before running dpkg-reconfigure. But it's
> possible I might be able to find a way of phrasing it for you, if
> you wouldn't mind starting by explaining it to me.
Ok, convinced.
> >>> NOTE: selecting "No automated setup" can leave previously created mirror
> >>> configuration behind, which needs to be updated by cache administrator manually.
> It's bad style to shout at the user (NOTE that this is an
> imperative form!), but there's no absolute rule against explicit
> second person forms (compare "from a mirror of your choosing" a few
Fine.
> > Second, it should be mentioned that something is already there. Some
> > users where bitching about old configuration left there and not kept
> > uptodate anymore.
>
> It covers that already - "any updates [...] will need to be
> performed manually". Or is the problem that you can guarantee that
> this process _will_ leave the admin with manual work to do? If so,
Yep, this is likely to happen when people reconfigure the package or see
the message during the next dist-upgrade to Stable.
> "any" is inappropriate there, and it should be something like
>
> Selecting "No automated setup" will leave the existing configuration
> unchanged. It will need to be updated manually.
>
> (Getting rid of the second person pronoun in passing.)
Perfect!
> >> 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?
>
> I was working on the basis that it makes more sense to start by
> describing the use case this software is "primarily targeted at";
> this is after all the description for a .deb that I'm downloading
> via APT, not a blurb for the upstream website. However, it would be
> easy enough to either add a mention of RPM-style software
> repositories or just subtract the "Debian-style" - there's no need
> to throw away the whole thing.
Alright. But I think it should become specific enough in the first sentence.
The rationale is: it's for Debian and compatible... but you can cache
other stuff if you want.
> > Description: Caching proxy for distribution of software packages
>
> And again you've reverted to the original, complete with
> non-DevRef-compliant capitalisation.
"Reverted" sounds evil, I just forgot to merge it. Rereading mine
version, I don't like it now. I don't like yours either, we don't cache
"the source". IMHO the one from approx sounds better:
Description: caching proxy server for Debian archive files
Making it more generic may make more sense... I cannot decide.
Description: caching proxy server for system distribution package files
> > 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.
>
> Didn't you just finish saying that this "yet another implementation"
> stuff was lame? But here it is again, with all our fixes thrown
> away. Must I go through line by line pointing out each individual
Ooops, I copy-pasted the old version, sorry for inconvenience
(really, you get a beer from me if we meet in real life).
Here is the version I was talking about plus changed short description:
Description: caching proxy server for Debian archive files
Apt-Cacher NG is a caching proxy for download of packages from Debian-style
software repositories and may also support other package types.
.
The main principle is a central machine which hosts the proxy for a local
network, and clients configure their APT setup to download through it.
Apt-Cacher NG keeps a copy of all useful data that passes through it, and when
a similar request is made, the cached copy of the data is delivered without
being re-downloaded.
.
Apt-Cacher NG has been designed from scratch as a replacement for
apt-cacher, but with a focus on maximizing throughput with low system
resource requirements. It can also be used as replacement for apt-proxy and
approx with no need to modify clients' sources.list files.
And the changed templates file:
__Choices: Set up once, Set up now and update later, No automated setup
_Default: Set up once
_Description: Configure apt-cacher-ng for request URL remapping?
Apt-cacher-ng can download packages from remote sites different from the ones
that client system assume to download from. The advantage of this method is
an easier initial configuration of client systems and the possibility of
a quick mirror change afterwards.
.
This remapping of URLs can be configured now in an automated way 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).
.
Selecting "No automated setup" will leave the existing configuration
unchanged. It will need to be updated manually.
Thanks,
Eduard.
--
Das hat der liebe Gott nicht gut gemacht. Allen Dingen hat er Grenzen
gesetzt, nur nicht der Dummheit.
-- Konrad Adenauer
Reply to: