Re: Please review vidalia debconf template
> Template: vidalia/info
> Type: note
"Type: note" is generally discouraged (DevRef 6.5.3.1.6)...
> _Description: About Vidalia and the Tor software interaction
> Vidalia provides a GUI for the Tor software. That means that Vidalia needs to
> talk to the Tor software for configuring different aspects of the Tor Network,
> view its status at a glance, monitor its bandwidth usage or just view logs.
There's no such thing as a software, so this repetition of "the X
software" is unidiomatic. And it's phrased as if it's Vidalia
that's going to "view its status at a glance". It's hard to see
what's intended, but I'm guessing:
Vidalia provides a graphical user interface to configure various aspects of
the Tor Network, check its status at a glance, monitor its bandwidth usage,
or just view logs. This means that Vidalia needs to talk to the Tor daemon.
This repeats material from the first paragraph of the vidalia
package description (which anybody installing vidalia should already
have read), except claiming a couple of extra bits of functionality.
If vidalia can now do extra things, don't tell me about them now -
revise the package description to advertise them to me *before* I
decide whether to install it!
> .
> The component of the Tor software that Vidalia talks to is a daemon process,
> which works on background without any user interaction required.
Junk paragraph.
> .
> There are two different ways to let Vidalia communicate with Tor:
> .
> - Letting Vidalia start Tor process on its own.
> (Simplest for end users, can't be used in a multi-user desktop)
> .
> - Enable Tor to use a control port to communicate with Vidalia.
> (Recommended for stronger security, preventing privilege escalation attacks)
> .
> For more information please read '/usr/share/doc/vidalia/README.Debian'.
You could boil the whole thing down to something like:
Vidalia needs to communicate with the Tor daemon so that it can provide a
graphical user interface for it. This can work in either of two ways:
* let Vidalia start the Tor process
(simple but not usable on a multi-user system);
* give Tor a control port to communicate with Vidalia
(recommended to prevent privilege escalation security exploits).
For more information see "/usr/share/doc/vidalia/README.Debian".
So... when I read that README, is there going to be some action it's
going to advise me to perform? If not, this note is definitely
debconf abuse; but if so, it would be nice to get some hint of it
here.
Or if this note is background information that the user needs to
have read to act upon the following "Type: select" prompt, wouldn't
it make more sense to incorporate this text into that template?
> Template: vidalia/tor-daemon-interaction
> Type: select
> Choices-C: no, yes-now, yes-always
> __Choices: No, Yes (just for now), Yes (and disable it for every boot)
> Default: yes-always
> _Description: Let Vidalia start Tor after stopping existing Tor process?
The trouble with this description is that it could be followed by
the options "yes, do them in that order/no, do them in the opposite
order". Couldn't it be phrased as:
_Description: Stop Tor and let Vidalia restart it?
(Assuming "select" templates are allowed to have a question mark...
I can't remember where the rules for that live.)
> Vidalia's installation found a Tor process running. In order for Vidalia to
> work, choose between these three different ways of starting the Tor process:
"No" doesn't sound much like a way of starting the Tor process.
Tor is already running. Please select a method to allow Vidalia to
communicate with the Tor daemon.
> .
> If you choose 'No', Vidalia will give for granted that Tor process will be
> always running, which is the default package behaviour
> (Recommended for a multi-user desktop)
It's unclear to me what this is saying will happen. Maybe:
If you choose "No" (the default, recommended on a multi-user system),
Vidalia will assume that Tor should always be running.
This is counter-intuitive. Will vidalia use the control-port
arrangement mentioned above?
> .
> If you choose 'Yes (just for now)', Vidalia will inmediatelly stop the Tor
> process, so Vidalia could start Tor process this time, and will assume that
> Tor will be always running in next reboots
Maybe:
If you choose "Yes (just for now)" Vidalia will restart the Tor process,
and will assume that Tor should always be running in future after reboots.
I really don't understand this. Is it saying Vidalia will in future
let Tor start on its own, and therefore be unable to communicate
with it? Or that Vidalia will take over the job of starting Tor on
reboot (always)?
> .
> If you choose 'Yes (and disable it for every boot)', Vidalia will configure
> the Tor software not to start by its own on every boot and allow it to be
> launched by Vidalia (Recommended for end users)
Maybe:
If you choose "Yes (and disable it for every boot)", Vidalia will configure
Tor not to start on its own after reboots, allowing it to be launched by
Vidalia (which is simplest for users).
> .
> In doubt, leave default answer selected.
> (Will be able to change it at any time by running 'dpkg-reconfigure vidalia')
We're supposed to be able to assume that the default option is a
sensible default, so this shouldn't need saying. However, given
that you've said one of the alternatives is "recommended for end
users" perhaps you could explain some of your reasoning here.
If I was confident I understood what the options meant I would
suggest some complete rewrite along the lines of:
Template: vidalia/tor-daemon-interaction
Type: select
Choices-C: controlport, auto, manual
__Choices: Control port, Auto-restart, Manual restart
Default: control-port
_Description: Vidalia/Tor communication method:
Tor is already running. Please select a method to allow Vidalia to
communicate with the Tor daemon.
* Control port: leave Tor running and communicate via a control port
(recommended on a multi-user system);
* Auto-restart: stop Tor and let Vidalia start it (now and
automatically on reboots, so that Tor is always running);
* Manual restart: stop Tor and just let Vidalia start it whenever
you run Vidalia.
But probably this isn't accurate...
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Reply to: