On Jan 9, 2008 3:58 PM, Matrix Mole <matrixm@gmail.com> 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.

Just to let you know, a few of us have noticed this. It's been reported here: http://trac.macosforge.org/projects/macports/ticket/13742 I haven't had time to try the requested operation, but for anyone who can, I think the feedback will help determine why MacPorts 1.6 is behaving this way on 10.5 installs. Patrick

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.