10.5 and $PATH variable

[Juan Manuel Palacios]

On Jan 9, 2008, at 5:28 PM, Matrix Mole wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I just obtained a new mac mini today with Leopard installed on it.  
> Since
> this is my first experience with 10.5, I'm still learning some things.
> One of the first things I did though was to install macports. After  
> the
> installation, I noticed that the .profile file wasn't modified to
> include /opt/local/bin and /opt/local/sbin like my 10.4 version was.  
> At
> least, I think I installed the 10.4 version from the dmg image.
>
> Anyway, after doing a little looking around on the file system and
> reading the startup files, I discovered two things. First, there is no
> default .bash_profile, .bashrc, or .profile in the users startup
> directory. No problem there, just left up as an experience for the  
> user
> to perform if they need to customize their environment beyond the
> default. Secndly, I learned that Leopard has /etc/paths and
> /etc/manpaths files that are used during login to set the default  
> paths
> and manpaths. By adding /opt/local/bin and /opt/local/sbin to /etc/ 
> paths
> and putting /opt/local/man into the man path, I can guarantee that  
> these
> are added to the path for any user on the system.
>
> This is actually a pretty cool idea, and it prompted the reason for my
> email. Could it be possible to modify the port install scripts to add
> it's paths to those two files on 10.5? Those files don't exist nor are
> used on 10.4 as I already checked, so the 10.4 install scripts  
> wouldn't
> need modified.
>
> Just wondering, and not even sure if this has already come up and been
> discussed to death. Since I just got Leopard, I hadn't been reading
> anything related to that version up till now.


	For the record, MacPorts developers are still somewhat figuring out  
the best possible way to tweak a user's environment to include  
MacPorts compatible settings.

	1.6.0 sources and the pkg installers are pulled from the  
"release_1_6" subversion branch, and in it the adopted approach is the  
pkg's "postflight" script, which I authored, that gets run by  
Insaller.app when the pkgs are used. Unfortunately, this script has  
been exhibiting some bugs that I haven't been able to reproduce  
locally in order to fix them, even though I tested and debugged it  
thoroughly before putting it into production. I'm actively looking  
into these issues, rest assured.

	"trunk" sources (that is, unreleased code) approach the problem of a  
MacPorts compatible environment by making use of the Leopard specific / 
etc/paths.d and /etc/manpaths.d directories, as originally posted in  
this thread. But that, added to being a Leopard only solution (and  
thus leaving the still larger Tiger users pool out in the cold), also  
creates other problems for us, since it *appends* MacPorts settings to  
the environment (e.g., /opt/local/bin being at the end of $PATH) while  
it has been established that it is best if they are *prepended* (/opt/ 
local/bin being at the *start* of $PATH).

	So as you can see, there's still no silver bullet for this problem,  
so please bear with us.

	As for the workings of the "postflight" script in the 1.6.0 pkg  
installers, please read "details of the postflight script" at http://guide.macports.org/#installing.macports 
  to become acquainted with the several reasons why the script might  
not tweak the environment, as there are several. In short, the script  
refusing to tweak a non-vanilla environment (or, obviously, refusing  
to touch already customized ~/.profile or ~/.tcshrc files) is not  
necessarily a bug.

	As for the bugs that do exist, there are seemingly two macro cases:

1) the environment tweaks work as expected but then the script fails  
to selfupdate the MacPorts installation due to rsync blocking on the  
user's side: this is a completely harmless failure and thankfully a  
very easy one to fix both by us and users experiencing it. The latter  
should simply ignore the error and figure out how to unblock rsync to  
then run "selfupdate" manually (or switch to other MacPorts updating  
means, but that's an entirely different discussion). Some reports in  
ticket #13742 have mixed this case in. Please ignore them.

2) the user's environment is a vanilla one, but for some still  
undetected reason the script fails to tweak it to make it MacPorts  
compatible. This is obviously an important bug and what I'm focusing  
my energies on fixing, what ticket #13742 should be about.


	Any help in getting this fixed will be greatly appreciated. I'll  
analyze the feedback already received and will try to post new  
questions/instructions in order to find the bugs and squash them.

	Thank you all for your help! Regards,...


-jmpp

PS: There's also the "The following install step failed: run  
postflight script for	MacPorts-1.6.0." thread on this very list,  
discussing the same problems. I'll try to keep discussion concentrated  
there and will from now on reply only to that one.