Re: Question on title and explanation of shuffles
Osamu Aoki wrote:
>> Did I? No, surely I took them out in Chapter 4. 5.15 looks like an
>> oversight.
>
> I now realize I may not have applied patch for Chapter 4. Did you send
> me one which I overlooked? Can you resend it to me. i could not find
> one on this mailing list. Sorry.
I've still got my "out-tray" copy, but you're right, somehow it never
reached the list. I'll try again with a refreshed patch later.
>> --- maint-guide.en.dbk.pristine 2011-04-30 12:52:45.588927791 +0100
>> +++ maint-guide.en.dbk 2011-04-30 18:09:40.025258209 +0100
>> <para>
>> -If you are making a Debian specific package without an upstream program instead,
>> -typical workflow of the Debian package building is simpler.
>> +If instead you are making a Debian-specific package with no upstream, the
>> +typical workflow of Debian package building is simpler.
>> </para>
>
> I understand this but this colloquial insertion of "instead" may confuse
> non-native readers. How bad is the following alternative?
I'm not aware of any colloquial overtones to this use of "instead"
(originally a calque of legal Latin!); but I can imagine it might be
an en_GBism, and the more I look at it the more convoluted the usage
rules get... so okay, let's avoid it.
> Instead, if instead you are making a Debian-specific package with no
> upstream, the typical workflow of Debian package building is simpler.
I'll assume the second "instead" is a typo. If so: not quite right.
The distinction between "instead, if" and "if instead" is that "if
instead" has the "instead" operating within the conditional clause.
• "Instead, if its sunny, I'll go out": that's instead of some action
previously mentioned (such as staying in and working). This
could also be phrased as "if its sunny, I'll go out instead".
• "If instead its sunny, we'll go out": that's instead of some other
sort of weather previously mentioned (such as rain). This
could also be phrased as "if its sunny instead, I'll go out".
I wouldn't recommend moving the "instead" in the quote above to the
very end of its conditional clause, but in principle you could use:
If you are instead making a Debian-specific package with no
upstream, the typical workflow of Debian package building is simpler.
The following seems a much more robust option:
On the other hand, if you are making a Debian-specific package with no
upstream, the typical workflow of Debian package building is simpler.
>> - <listitem><para>single binary package, arch = all (executables written in the POSIX shell language)</para></listitem>
>> - <listitem><para>single binary package, arch = all (executables written in interpreter languages)</para></listitem>
>> + <listitem><para>single binary package, arch = all (executables written in an interpreted language such as POSIX shell)</para></listitem>
>
> I get your point but I erased too much. Since POSIX shell is easier
> than Perl and Python, I had:
And the not-strictly-POSIX bash shell is arguably even easier than
dash, since it just requires you to string together commands that you
can test in an ordinary login shell. It's perfectly legitimate to put
a bash hashbang at the top of your scripts... or indeed to write in
ksh or zsh, if that's what you're used to. So maybe we should just
omit the word "POSIX".
> <listitem><para>single binary package, arch = all (executables written in the POSIX shell language)</para></listitem>
> <listitem><para>single binary package, arch = all (executables written in interpreter languages such as Perl and Python)</para></listitem>
>
> or
>
> <listitem><para>single binary package, arch = all (executables written in the POSIX shell language)</para></listitem>
> <listitem><para>single binary package, arch = all (executables written in Perl and Python)</para></listitem>
>
> Any other languages are a bit more complexities. What should I do?
The first version implies that it's the interpretedness that puts them
in the "easy" category, and that you would therefore include things
written in Ruby or PHP if the reader wanted to package those. If you
mean Perl or Python specifically, there's no need for these to be two
separate lines:
<listitem><para>single binary package, arch = all (executables written in shell, Perl, or Python)</para></listitem>
>> +There is another old Latin saying: <emphasis>fabricando fit faber</emphasis>
>
> Should I change this to "There is an old Roman saying ..." as you
> mentioned in the other place?
No, it's still also true that it's Latin, so keep it phrased this way
(as "another" alongside the Seneca quote).
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Reply to: