Hello Marc! On Dec 3, 2007, at 7:28 AM, Marc André Selig wrote:

Let me start out by saying I find this whole business of modifying users' files without telling them so quite awkward.

Please note that all this path & manpath munging, user specific against system wide files modification is only meant to happen from the pkg installer (off of its postfligth script located in svn's base/ portmgr/dmg) which: *) Does warn users in the welcoming ReadMe.rtf file displayed by the installer that their environment will be modified for MacPorts usage; *) As it is aimed at a group of users who either don't want or don't know how to install from source, it is configured in the most standard fashion possible and, as such, it is only meant to work in that situation. If you're experienced enough to modify your system in meaningful ways, such as placing your profile file in a read-only image, then surely you're savvy enough to install from source and setup your own MacPorts environment (no project at all can afford to construct hand-holding installers of their software and instructions for more than a bare couple of usually similar-among-them scenarios). This is also made clear througout the documentation: ReadMe.rtf, website, guide, etc. If you feel we're still not being clear and forthcoming enough about this scenario and assumptions we're presenting the user with, then please feel most free to suggest improvements anywhere you might find them appropriate.

On Dec 3, 2007 6:14 AM, Juan Manuel Palacios <jmpp@macports.org> wrote:

...

*sh) if $SHELL -lc "/usr/bin/env | grep -q MANPATH" && ! $SHELL - lc "/usr/ bin/printenv MANPATH" | grep -q /opt/local/share/man; then echo "export MANPATH=/opt/local/share/man:\$PATH" >> $HOME/.profile fi

This would fail silently on my account, where ~/.profile is symlinked to a read-only image under normal circumstances.

This is a new instruction that would print further content into the profile file, yes. But note that overall behavior is unchanged: if that fails for you, then the entire postflight script fails because prior to that there are also other instructions printed to the profile. Your "bug report" is not applicable, I'm afraid to say, the postflight script is simply not meant to work with your setup. Nevertheless, as I said above, please feel most free to suggest any improvements you might find appropriate, like some welcomed error catching.

If you don't catch the error, things would go from "it fails unless you do everything in the documentation" to "it fails if you do the things in the (shortened) documentation; read the source if you want to get it working again".

What documentation are you referring to? What's the shortened version that's leaving you in a rather lost state?

I clearly prefer the old variant (more things to do, but if you do them all, things work) to the new one (it works magically if your installation is pure standard, but fails in mysterious ways otherwise).

There is no old and new way. We've had this postflight script for a long time already and all we're doing now is enhancing it to fill avoid we're encountering on Leopard (an appropriate setting for MacPorts installed man pages). James' enhancements writing to /etc/ [man]paths.d/ were deferred because they are not yet polished enough for production time, so we're aiming for this alternative through the same postflight script that, if it doesn't work for you now because of the setup you describe, it simply couldn't have worked for you earlier either. Also, magically working on a pure standard scenario but failing unexpectedly on different ones is precisely what the pgk installer and its postflight script are meant to do, that's expected behavior. If you're on the latter crowd, then please install from source. We as a team have not discussed putting together binary installers to cover for other scenarios than the pure standard one. I'm not saying we *wont* do it, but rather that we simply haven't; if we do, then I'm sure mixing its settings/considerations/assumptions with the ones of the pure standard scenario would be a very bad approach. In such case we'd be building two or more completely different and separate installers, each with its own private set of resources.

Just the point of view of a mere user. :-)

And appreciated! Would love to study whatever enhancement you might propose.

Regards, Marc

PS: I agree that modifying the local user's preferences is preferrable to modifying /etc. I still think it needs to be pointed out quite clearly in the installation manual (i.e. you don't get to shorten the manual if you do this). Otherwise, everybody who has one account for each user (plus one account for managing the machine) will not know to add your stub to the .profile of each user who wants to use MacPorts.

Those are interesting documentation enhancements, making it clear that the environment we're setting up will only work on a per user basis.

PPS: Another story from the point of view of a mere user: I've had people apparently locked out from their machine because they had /opt/local/bin first thing in their PATH and some port had pulled in a version of sudo that did not work. I've been telling people to put /opt/local/bin at the end ever since.

That should definitely be filed as a bug in our Trac. In fact I think it was and I also think it was fixed, but I don't have any reference to that, sorry. Regards,... -jmpp