Re: [RFR] templates://apt-cacher-ng/{apt-cacher-ng.templates}
#include <hallo.h>
* Jonathan Wiltshire [Fri, May 29 2009, 12:09:37AM]:
> --- ../apt-cacher-ng.old/debian/apt-cacher-ng.templates 2009-05-27 20:37:13.000000000 +0100
> +++ debian/apt-cacher-ng.templates 2009-05-28 22:48:07.000000000 +0100
> @@ -1,20 +1,18 @@
> Template: apt-cacher-ng/modifytargets
> Type: boolean
> Default: true
> -_Description: Configure apt-cacher-ng to transparently reroute requests to different mirrors?
> - Apt-cacher-ng can silently and transparently reroute user requests to
> - different mirror(s). To simplify required configuration this setup can create
> - or modify lists of target hosts.
> +_Description: Transparently divert requests?
>
> The description was far too long. This brevity turns it into a much more
> elegant question
Maybe, but this...
> + You can choose how this feature should behave in the next step.
>
> As it's a boolean, we just need a simple yes or no. Split the paragraph
> to make it easier to read.
...
> It doesn't make any sense asking the user whether to enable re-routing,
> and then effective ask again in the next question. So, since there are
... tells me that the purpose of the question set is hard to understand
because you didn't. Let me elabote: the original idea for this questions
was a selection box with four options.
- Setup rerouting and always manage
- Setup rerouting once
- Don't configure automaticaly (it's modified by the user)
- Don't reroute at all (disables/resets previously created config)
The last options are not just the logical siblings or opposites, we are
talking about two variables in the equation (configured by user or by
setup? auto-modified once or always?). And it's intended for people
that want a previously created setup go away since former releases
created that config silently.
Unfortunatelly explaining all that in the preamble made the text look
very bloated, therefore I tried to split it into two questions.
> This obviously changes the maintainer script quite a lot. Eduard,
> are you happy to make a change this big? For the purposes of this RFR,
> I'll assume so, but please indicate your preference one way or the
> other.
I would change the debconf processing part as soon as it starts making
more sense, I am not really happy with the current version.
> --- ../apt-cacher-ng.old/debian/control 2009-05-27 20:37:13.000000000 +0100
> +++ debian/control 2009-05-28 22:31:21.000000000 +0100
> @@ -9,20 +9,20 @@
> Architecture: any
> Depends: ${shlibs:Depends}, ${misc:Depends}, adduser
> Recommends: perl (>> 5.8), ed
> -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.
> +Description: caching proxy for distribution of software packages
>
> Lose the capital letter so that it's in is-a form.
>
> + Apt-Cacher NG is yet another implementation of an HTTP proxy for
>
> 'an'
>
> + software packages. It is primarily designed for .deb packages but
> + may also be used with other package types.
>
> Break the sentence up a bit. Lots of other distributions besides us and
> Ubuntu use the .deb package format. Grammar in the last line.
I would change the last part to: It is primarily designed for Debian
package files but may also be used with many other file types related to
software package distribution.
Rationale: First, ".deb" is not the official name of the format. Second,
other distros are using the Debian tools, why should we try to hide this
fact? Third, it's not just about .deb but various other files which
belong or accompany Debian package files (source package file types,
pdiffs, some jigdo support files and some meta-files from Ubuntu, etc.)
and even RPM related can be used (reported by user, not verified yet).
> + It follows principles similar to many other solutions
> + and serves the same purpose: a central machine presents the
Ok.
> + 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 fetching it from
> + the repository all over again.
Sounds good.
> - Apt-Cacher NG is more than a simple rewrite of Apt-Cacher. It was redesigned
> - from scratch and is written in C++ with main focus on maximizing throughput
> + Apt-Cacher NG has been designed
> + from scratch with a focus on maximizing throughput
> with low requirements on system resources.
>
> With my user's hat on, I don't really care what language it's written in
> or what it's history is. I just care that it's lean and won't hog all my
> memory if I run it on a small box.
Maybe, but it's oversimplified now. This paragraph was added for users
that DO want to know the major difference between this package and
apt-cacher. What about following:
Apt-Cacher NG has been designed from scratch as replacement of
apt-cacher but with focus on maximizing throughput with low requirements
on system resources.
Regards,
Eduard.
Reply to: