On Sat, Nov 21, 2015 at 09:58:07PM +0000, Justin B Rye wrote:
> David Kalnischkies wrote:
> > diff -ru pristine/apt.8.xml modified/apt.8.xml
> > --- pristine/apt.8.xml 2015-11-21 16:06:47.000000000 +0000
> > +++ modified/apt.8.xml 2015-11-21 16:40:48.824899321 +0000
> > @@ -72,7 +72,7 @@
> > <varlistentry><term><option>install</option>, <option>remove</option>, <option>purge</option> (&apt-get;)</term>
> > <listitem><para>Performs the requested action on one or more packages
> > specified via ®ex;, &glob; or exact match. The requested action
> > - can be overidden for specific packages by append a plus (+) to the
> > + can be overridden for specific packages by appending a plus (+) to the
> > package name to install this package or a minus (-) to remove it.
> > </para><para>
> > A specific version of a package can be selected for installation by
>
> Simple grammar fix. Oh, wait, nearly missed the typo in "overidden".
>
> (I'm always surprised that this doesn't cause problems for people
> trying to switch from memtest86+ to memtest86...)
("apt install memtest86+- memtest86" is one of your options. In general
real package name trumps modifier, so that is only a problem if you
aren't sure if memtest86+ is a real package (yet/still). Its probably
fair to say that name+ situations are confusing even without apt
sprinkling in modifiers. If all the authors managed to add is a +, they
might as well patch instead of fork the software… but just my 2ct)
> > </para><para>
> > This is the traditional format and supported by all apt versions.
> > Note that not all options as described below are supported by all apt versions.
> > - Note also that some older applications parsing this format on its own might not
> > + Note also that some older applications parsing this format on their own might not
> > expect to encounter options as they were uncommon before the introduction of
> > multi-architecture support.
> > </para>
> > </refsect1>
>
> Plural apps, so plural pronoun. Perhaps it should be something like
> "for themselves"?
Somehow "on their own" gives me the mental image of an application
standing in the woods at night completely alone expect that it is
surrounded by a pack of wolfs¹. Why oh why did this poor soul venture
into the woods without support?
"for themselves" on the other hand suggests to me a greedy character
possessing something of value which he (just) doesn't want to share.
As parsing this format is nothing to be proud of, but if you really have
to it is better done with a library who can do this rather than your own
homegrown code I like the first one better, even if it is probably just
me having these wild fantasies…
¹ I had to look up "The The" as the band is a decade older than I am.
I wonder if stories about big bad wolfs I heard as a kid have a similar
fate someday and I should therefore use "zombies" – but I don't like
them even if that might be better for the public image of real wolfs…
> > <listitem><para><option>By-Hash</option> (<option>by-hash</option>)
> > - can have the value "yes", "no" or "force" and controls if APT
> > - should try to acquire indexes via an URI constructed from a
> > + can have the value <literal>yes</literal>, <literal>no</literal>
> > + or <literal>force</literal> and controls if APT
> > + should try to acquire indexes via a URI constructed from a
>
> The following paragraph wraps its values in <literal> tags, so I'm
> assuming that's standard. And it's "a you are eye".
(Its 'standard' for apt, but we should probably use a different tag as
this one isn't styled in any way in the manpage, so the information what
the values are exactly is lost. "Probably" "the" "reason" "for" "".
Anyway, that is our problem, not yours…)
> > @@ -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.
> Thankyou, I've been short of things to proofread this month!
I not only learned about my (by frequency of writing about them)
favorite band, but "additionally" learned about some of my 'typo skills'
where it would be "beneficial" if I would "schedule" time to
"explicitly" and "securely" manage to have them "overridden". And as if
this wouldn't be enough: Manpages and strings showing up in all sorts of
package management "front-ends" were improved, too. So: Thank you! :)
Best regards
David Kalnischkies
Attachment:
signature.asc
Description: PGP signature