> On Feb 1, 2017, at 08:20, Bachsau <w...@bachsau.name> wrote: > > Am 01.02.2017 um 07:38 schrieb Ryan Schmidt: >> Sorry. Repeated modifications of the profile when the modifications were >> already there was a bug. It looks like a fix was committed, so hopefully >> 2.4.1 will not have this bug anymore. > > Not only repeated modifications. It simply should not do that in any case, > without asking back! > >> Using /etc/paths to add the MacPorts paths is not recommended because that >> appends the MacPorts paths to the default, while we want the MacPorts paths >> to be prepended. We want MacPorts versions of software to supersede probably >> older versions provided by the OS, not vice versa as using /etc/paths will >> do. > > It depends on the order in your /etc/paths. If I put it first, it is first. > The advantage of /etc/paths is it is applied even to the graphical > environment, not just when running a login shell.
Oh, I was thinking of /etc/paths.d https://trac.macports.org/ticket/24105 >> The MacPorts installer has always done this. I'm pretty sure it tells you it >> will do this, and our documentation says so too. > > It did not, never. The installer's Read Me page says: > A file named ~/.profile is created for the "bash" shell (default on Mac OS X > 10.3 and newer) during the MacPorts installation. It contains the necessary > statements to append MacPorts' binary paths within /opt/local/ to your shell > environment, so MacPorts is available to you on subsequent terminal sessions. > You may have to quit and restart your terminal application for this change to > take effect. The guide says: https://guide.macports.org/#installing.shell > MacPorts requires that some environment variables be set in the shell. When > MacPorts is installed using the OS X package installer, a “postflight” script > is run after installation that automatically adds or modifies a shell > configuration file in your home directory, ensuring that it defines variables > according to the rules described in the following section. Those installing > MacPorts from source code must modify their environment manually using the > rules as a guide. > > Depending on your shell and which configuration files already exist, the > installer may use .profile, .bash_login, .bash_profile, .tcshrc, or .cshrc. >> The alternative is that the user installs MacPorts, then when they try to >> use it they get an error that "port" could not be found in the path; this >> will cause tons of support requests that I would prefer to avoid, so I'd >> like to keep things the way they are, with the installer modifying the >> user's profile when needed. > > People using MacPorts are those who know about the insides of their system > and want to customize it. I think they should at least be able to read and > follow documentation. This is definitely not the case. There are many nontechnical users who are directed to MacPorts by other projects (such as Inkscape) and they only want to install that project; they don't want to understand how MacPorts or the shell works. We should work toward making MacPorts easier for nontechnical users, not harder.
