PATH deals with binaries, not libraries

[Jan Stary]

On Mar 22 07:48:55, hans at stare.cz wrote:
> As discussed currently on -users, here is a diff
> that stops postflight messing with the user's config
> and edits the correspondng parts of installing.xml

Even if this gets rejected (as it seems to be the consensus
to edit the user's shell configuration during the install),
there is one bit of wording in installig.xml that I think
should be changed (see diff below).

The PATH is where shell commands and shell scripts look for binaries.
It has nothing to do with where a running binary looks for _libraries_,
right? (Or does it?)

Also, the MacPorts paths are "prepended", not "appended" to the PATH.
And it doesn't change the "default" PATH, it changes what the user has.
And it doesn't matter whether it's "ported software".

	Jan


diff --git a/guide/xml/installing.xml b/guide/xml/installing.xml
index 31f8719..9dcb4be 100644
--- a/guide/xml/installing.xml
+++ b/guide/xml/installing.xml
@@ -436,10 +436,9 @@
                 <listitem>
                     <para>Required: <varname>PATH</varname> variable</para>
 
-                    <para>This variable is set by the postflight script to append the MacPorts executable paths to the
-                        default path as shown. The MacPorts paths are appended at the front of <varname>PATH</varname>
-                        so the MacPorts libraries will take precedence over vendor-supplied libraries for ported
-                        software at runtime.</para>
+                    <para>This variable is set by the postflight script to prepend the MacPorts executable paths to the
+                        current path as shown. This puts the MacPorts paths at the front of <varname>PATH</varname>
+                        so that the MacPorts binaries will take precedence over vendor-supplied binaries.</para>
 
                     <programlisting>export PATH=/opt/local/bin:/opt/local/sbin:$PATH</programlisting>