Re: Request for Review: APT manpages
David Kalnischkies wrote:
>>> @@ -270,11 +274,11 @@
>>> is considered trusted or if warnings should be raised before e.g.
>>> packages are installed from this source. This option can be used
>>> to override this decision either with the value <literal>yes</literal>,
>>> - which lets APT consider this source always as a trusted source
>>> - even if it has no or fails authentication checks by disabling parts
>>> - of &apt-secure; and should therefore only be used in a local and trusted
>>> + which lets APT consider this source always as a trusted source,
>>> + even if it lacks or fails authentication checks, by disabling parts
>>> + of &apt-secure;. It should therefore only be used in a local and trusted
>>
>> Needs heavier punctuation. "Has no or fails" is just confusing.
>
> I have taken the suggestion as "has no" wasn't any better in this
> regard, but isn't "lacks or fails authentication checks" technically
> wrong as the checks aren't lacking, but the information the checks could
> be applied to? Maybe we should just drop the first or-part given that
> I fail a test not only if I answer too few questions correctly, but also
> if I don't show up at all.
So maybe "even if it doesn't pass authentication checks"? Or even
"regardless of authentication checks"? And wait a minute, "either
with the value <literal>yes</literal>" or what? The sentence never
gets round to producing an "or" clause, so I would suggest rephrasing
it less convolutedly:
<option>Trusted</option> (<option>trusted</option>)
is a tri-state value which defaults to APT deciding if a source
is considered trusted or if warnings should be raised before e.g.
packages are installed from this source. This option can be used
to override that decision. The value <literal>yes</literal> tells APT
always to consider this source as trusted, even if it doesn't pass
authentication checks. It disables parts of &apt-secure;, and should
therefore only be used in a local and trusted context (if at all) as
otherwise security is breached. The value <literal>no<literal> does
the opposite, causing the source to be handled as untrusted even if
the authentication checks passed successfully. The default value can't
be set explicitly.
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Reply to: