Re: Where should non-macports sw be installed? (Was: Problem with Macports, homebrew, and ghostscript)
On 2014-02-12, at 3:50 PM, Art McGee wrote: On a related note, Homebrew is actually based on GNU Stow. It's basically a clone/ripoff with enhancements. If you're going to use Homebrew, then use it in the same way suggested for Stow, and install packages in your home directory, leaving /usr/local alone. Where in the world did you get this idea? Firstly, all that Stow does is make symlinks from a place where the software is actually installed to another (like /usr/local) where it's convenient to access and run. Homebrew is much more like Macports in that it can download the most recent version of a software package, compile it, test it, install it in a unique destination and *then* symlink it to /usr/local. Not to mention that Homebrew is Ruby and Stow is Perl-based. If you had said that homebrew is a ripoff of Macports, or rather, a reinvention, then you'd be closer to the mark. Davor___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Where should non-macports sw be installed? (Was: Problem with Macports, homebrew, and ghostscript
I also install into /opt/something where something expands to something descriptive of all the crap I am installing in there. Then I can turn PATHs on and off depending. This is really important for playing with things like the gtk+ cocoa that needs its whole space to itself. Just DONT use /opt or /opt/local of course. I also set them to be owned by my user, so I don't have to sudo to install. If I do, I know something is up. Mark --Mark ___ Mark E. Anderson e...@emer.net On Wed, Feb 12, 2014 at 10:56 AM, Arno Hautala a...@alum.wpi.edu wrote: On Wed, Feb 12, 2014 at 10:04 AM, Gregory Shenaut gkshen...@ucdavis.edu wrote: I understand why installing in /usr/local can mess up macports, but macports doesn't have everything, and most third-party software wants to go into /usr/local. Where should this stuff go, if not /usr/local? I install everything into my home folder. ./configure --prefix=~/local/ make make install If you need it available system-wide, just pick some other custom location (ie. /custom/). In any case, just make sure you're consistent (update your PATH) and point your configure script to the right place if the software can't find the libraries in your path or you need to override libraries that are in your path. The longer answer is that I use stow (http://www.gnu.org/software/stow/ ; and available in MacPorts) to assemble the bin, man, etc. directories. Stow isn't required, but it does help manage the software that isn't being managed by MacPorts. So, I might install a piece of software with: ./configure --prefix=~/local/stow/foo-1.2.4 make make install cd ~/local/stow stow foo-1.2.4 Stow just allows you to easily add and remove versions of software by linking a hiearchy of directories into a common location. I might have foo-1.2.4, foo-1.2.6, bar-3.9, but only have foo-1.2.4 and bar-3.9 active. I can the upgrade to foo-1.2.6 by running: cd ~/local/stow stow -D foo-1.2.4 stow foo-1.2.6 rm -rf foo-1.2.4 -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Where should non-macports sw be installed? (Was: Problem with Macports, homebrew, and ghostscript
On Feb 14, 2014, at 08:46 , Mark Anderson e...@emer.net wrote: I also install into /opt/something where something expands to something descriptive of all the crap I am installing in there. Then I can turn PATHs on and off depending. This is really important for playing with things like the gtk+ cocoa that needs its whole space to itself. Just DONT use /opt or /opt/local of course. I also set them to be owned by my user, so I don't have to sudo to install. If I do, I know something is up. I've been reluctant to use anything under /opt because in the event I ever need to scrub macports and start over, it's easier to remove /opt and reinstall macports from scratch. I'm currently installing all my own programs scripts in my home directory, with traditionally named folders like bin, doc, include, lib, libexec, man, share, src, var, and tmp. There are a few downloaded apps there too, but there are also a few where it seemed like too much work to keep them from going right into /usr/local where they belong. For a while, I had a separate sub-hierarchy in my home directory, with a symlink in / pointing to it; that way, I could refer to things I installed as /whatever/... and so on, as an alternative to ~/whatever/... But I decided that since I'm the only one that uses my Mac, I was just being compulsively traditional in making those things accessible from the root. It's a pity that macports isn't an official part of the system, like the freebsd ports are in fbsd, because if it were, then they (and not other ports) could simply install things right into the main system hierarchy. I believe that historically, really core elements of the OS went into /bin /lib and so on (this was back in the days when the root volume couldn't be very large), where “extra” things of interest to users things went into /usr/bin /usr/lib and so on (sometimes these were each on different physical drives). Locally-written things went into /usr/local, also often on a separate drive. When Berkeley started distributing their collections of software, they used /usr/ucb to keep it separate. For most unixy systems, that's really all you need, because an official ports system can then install things wherever they like without messing themselves up. But on the Mac, since there never has been an official ports system, there is competition between standard utilities wanting to be installed in /usr/local and several different ports systems. As a result we have /opt /sw and so on (I have no idea why the original pattern of /usr/ucb wasn't followed with /usr/mp, /usr/fink, and so on, but it wasn't), as well as a host of troubles when the assumptions of the various ports systems are violated. I suppose that's just another word for freedom. What I'm seeing from these responses is basically what I had always assumed, namely that macports doesn't really care where you install other software, as long as it isn't in /opt (or perhaps only /opt/local). Greg Shenaut ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Where should non-macports sw be installed? (Was: Problem with Macports, homebrew, and ghostscript
On Feb 14, 2014, at 11:56, Gregory Shenaut wrote: On Feb 14, 2014, at 08:46 , Mark Anderson wrote: I also install into /opt/something where something expands to something descriptive of all the crap I am installing in there. Then I can turn PATHs on and off depending. This is really important for playing with things like the gtk+ cocoa that needs its whole space to itself. Just DONT use /opt or /opt/local of course. I also set them to be owned by my user, so I don't have to sudo to install. If I do, I know something is up. I've been reluctant to use anything under /opt because in the event I ever need to scrub macports and start over, it's easier to remove /opt and reinstall macports from scratch. Feel free to install anything you like in prefix /opt/anything-other-than-local. That’s a great and standardized location for random other software to go that won’t interfere with MacPorts. The default MacPorts prefix is /opt/local. If you need to uninstall MacPorts, you can follow our uninstallation instructions, which will have you removing /opt/local and a few other paths, but not /opt/anything-other-than-local. What I'm seeing from these responses is basically what I had always assumed, namely that macports doesn't really care where you install other software, as long as it isn't in /opt (or perhaps only /opt/local). If you want to install random other software while also using MacPorts, I suggest you install that other software into a prefix that is not any of the following: * /usr * /usr/local * /opt/local * your MacPorts prefix (if different from /opt/local) * /sw And also avoid installing frameworks into /Library/Frameworks and of course /System/Library/Frameworks. I think that’s about it. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Where should non-macports sw be installed? (Was: Problem with Macports, homebrew, and ghostscript
On Fri, Feb 14, 2014 at 12:56 PM, Gregory Shenaut gkshen...@ucdavis.eduwrote: I've been reluctant to use anything under /opt because in the event I ever need to scrub macports and start over, it's easier to remove /opt and reinstall macports from scratch. Other third party software uses /opt as well (and even some Apple software; see xquartz). /opt/local is the only part that MacPorts touches; the rest of /opt is (and is there to be) fair game. It's a pity that macports isn't an official part of the system, like the freebsd ports are in fbsd, because if it were, then they (and not other ports) could simply install things right into the main system hierarchy. I believe that historically, really core elements of the OS went into /bin /lib This is a nightmare when installing newer versions of OS-provided things and when trying to keep base system and add-ons separate. Linux likes to pretend this is not a problem but its package managers are not really good enough to deliver on their claims; this often manifests as system upgrade failures. systems. As a result we have /opt /sw and so on (I have no idea why the original pattern of /usr/ucb wasn't followed with /usr/mp, /usr/fink, and so on, but it wasn't), as well as a host of /usr is often read-only on BSD-derived systems (while the relationship is now rather distant and I think OS X can't actually get away with r/o /usr, it is nevertheless BSD-derived and userspace is synced somewhat regularly with FreeBSD-CURRENT). /usr/ucb made sense in the original BSD context since it was populated as part of an OS install and could be considered read only afterward, plus you still had the original ATT versions of utilities available when needed for portability; aftermarket stuff doesn't really belong there (if you're remounting /usr r/w constantly to add software, you're doing read-only wrong) /opt originated on Solaris, in part to support read-only (or shared; consider zones) /usr, but it seems like everyone else has come up with their own justification for it. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Where should non-macports sw be installed? (Was: Problem with Macports, homebrew, and ghostscript)
Hi, So let's be a little more specific. You are saying that it's /usr/local/include and /usr/local/lib that are the problem, not /usr/local/bin, right? Otherwise you're saying that, for example, MacPorts is incompatible with BBEdit (which puts symlinks in /usr/local/bin). Very few ordinary installers install into /usr/local/include or /usr/local/lib, but a number install to /usr/local/bin. I don't see that as a major problem. Unfortunately it isn't that simple to tell – there might be software compiled using MacPorts that executes tools without absolute paths at runtime which could, depending on the order of directories in your $PATH variable pick up an incompatible version of something from /usr/local. I agree this possibility *is* getting rather remote, though. -- Clemens Lang ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Where should non-macports sw be installed? (Was: Problem with Macports, homebrew, and ghostscript
I understand why installing in /usr/local can mess up macports, but macports doesn't have everything, and most third-party software wants to go into /usr/local. Where should this stuff go, if not /usr/local? Greg Shenaut ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Where should non-macports sw be installed? (Was: Problem with Macports, homebrew, and ghostscript
On Wed, Feb 12, 2014 at 10:04 AM, Gregory Shenaut gkshen...@ucdavis.edu wrote: I understand why installing in /usr/local can mess up macports, but macports doesn't have everything, and most third-party software wants to go into /usr/local. Where should this stuff go, if not /usr/local? I install everything into my home folder. ./configure --prefix=~/local/ make make install If you need it available system-wide, just pick some other custom location (ie. /custom/). In any case, just make sure you're consistent (update your PATH) and point your configure script to the right place if the software can't find the libraries in your path or you need to override libraries that are in your path. The longer answer is that I use stow (http://www.gnu.org/software/stow/ ; and available in MacPorts) to assemble the bin, man, etc. directories. Stow isn't required, but it does help manage the software that isn't being managed by MacPorts. So, I might install a piece of software with: ./configure --prefix=~/local/stow/foo-1.2.4 make make install cd ~/local/stow stow foo-1.2.4 Stow just allows you to easily add and remove versions of software by linking a hiearchy of directories into a common location. I might have foo-1.2.4, foo-1.2.6, bar-3.9, but only have foo-1.2.4 and bar-3.9 active. I can the upgrade to foo-1.2.6 by running: cd ~/local/stow stow -D foo-1.2.4 stow foo-1.2.6 rm -rf foo-1.2.4 -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Where should non-macports sw be installed? (Was: Problem with Macports, homebrew, and ghostscript)
I understand why installing in /usr/local can mess up macports, but
macports doesn't have everything, and most third-party software wants to go
into /usr/local. Where should this stuff go, if not /usr/local?
Actually, I don't think there is that much of a problem with installing
software in /usr/local, the problem is the particular way that Homebrew
does it by default, taking over /usr/local completely, and it's disregard
for standard ownership and permissions.
As long as you insure that MacPorts comes before /usr/local in your paths:
export PATH=/opt/local/sbin:/opt/local/bin:${PATH}
export MANPATH=/opt/local/share/man:${MANPATH}
export INFOPATH=/opt/local/share/info:${INFOPATH}
you shouldn't have any problems.
I can only speak from personal experience, but I have lots of third-party
stuff installed in /usr/local from binary .pkg installers and manually, and
I haven't experienced any issues as a result of that.
On a related note, Homebrew is actually based on GNU Stow. It's basically a
clone/ripoff with enhancements. If you're going to use Homebrew, then use
it in the same way suggested for Stow, and install packages in your home
directory, leaving /usr/local alone.
Art
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Where should non-macports sw be installed? (Was: Problem with Macports, homebrew, and ghostscript)
Hi,
Actually, I don't think there is that much of a problem with installing
software in /usr/local, the problem is the particular way that Homebrew does
it by default, taking over /usr/local completely, and it's disregard for
standard ownership and permissions.
You're wrong on that one. The problem are the headers in /usr/local/include and
libraries in /usr/local/lib. Compilers *will* search there by default and
there's really no good way to tell them not to do that short of full-blown
sandboxing with all the gory details related to that (which is what trace mode
does).
As long as you insure that MacPorts comes before /usr/local in your paths:
export PATH=/opt/local/sbin:/opt/local/bin:${PATH}
$PATH doesn't really affect compiler's search paths. C_INCLUDE_PATH and
LIBRARY_PATH do that for newer clangs, but those won't stop compilers from
checking /usr/local, too.
Plus, your personal setting of $PATH doesn't affect MacPorts' $PATH variable in
any way – MacPorts will sanitize its own environment before it starts compiling.
export MANPATH=/opt/local/share/man:${MANPATH}
export INFOPATH=/opt/local/share/info:${INFOPATH}
As far as I know those aren't used on newer versions of OS X and are
automatically derived from the value of $PATH.
I can only speak from personal experience, but I have lots of third-party
stuff installed in /usr/local from binary .pkg installers and manually, and
I haven't experienced any issues as a result of that.
If those binary installers did install headers in /usr/local/include and
libraries in /usr/local/lib that has been pure luck. As soon as you install a
port that has an optional dependency not installed via MacPorts but present in
/usr/local you'll run into problems sooner or later.
--
Clemens Lang
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Where should non-macports sw be installed? (Was: Problem with Macports, homebrew, and ghostscript)
--On February 13, 2014 1:24:57 AM +0100 Clemens Lang c...@macports.org wrote: If those binary installers did install headers in /usr/local/include and libraries in /usr/local/lib that has been pure luck. As soon as you install a port that has an optional dependency not installed via MacPorts but present in /usr/local you'll run into problems sooner or later. So let's be a little more specific. You are saying that it's /usr/local/include and /usr/local/lib that are the problem, not /usr/local/bin, right? Otherwise you're saying that, for example, MacPorts is incompatible with BBEdit (which puts symlinks in /usr/local/bin). Very few ordinary installers install into /usr/local/include or /usr/local/lib, but a number install to /usr/local/bin. I don't see that as a major problem. Mike ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Where should non-macports sw be installed? (Was: Problem with Macports, homebrew, and ghostscript)
On Feb 12, 2014, at 18:24, Clemens Lang wrote:
export MANPATH=/opt/local/share/man:${MANPATH}
export INFOPATH=/opt/local/share/info:${INFOPATH}
As far as I know those aren't used on newer versions of OS X and are
automatically derived from the value of $PATH.
As far as I know they are used if you set them, but if you don’t set them they
are derived from $PATH so there is most often no need to set them.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Where should non-macports sw be installed? (Was: Problem with Macports, homebrew, and ghostscript)
On Feb 12, 2014, at 18:46, Mike Alexander wrote: --On February 13, 2014 1:24:57 AM +0100 Clemens Lang wrote: If those binary installers did install headers in /usr/local/include and libraries in /usr/local/lib that has been pure luck. As soon as you install a port that has an optional dependency not installed via MacPorts but present in /usr/local you'll run into problems sooner or later. So let's be a little more specific. You are saying that it's /usr/local/include and /usr/local/lib that are the problem, not /usr/local/bin, right? Otherwise you're saying that, for example, MacPorts is incompatible with BBEdit (which puts symlinks in /usr/local/bin). Very few ordinary installers install into /usr/local/include or /usr/local/lib, but a number install to /usr/local/bin. I don't see that as a major problem. I have not evaluated a statistically significant portion of all Mac binary package installers so I cannot state what portion of installers put files in /usr/local/include and /usr/local/lib vs. those that only install in /usr/local/bin. BBEdit is not a problem. It only installs its “edit” tool which lets you open BBEdit from the command line. It’s unlikely that any other software would deliberately detect that and alter its installation behavior as a result. The problem is headers in /usr/local/include and libraries in /usr/local/lib because compilers will look there automatically, without any special instructions. So if you install a library in prefix /usr/local that’s also installed by MacPorts, and you install another port with MacPorts that needs that library, will it use the MacPorts version or the /usr/local version? I don’t know. The only way I know of to make sure it doesn’t use the /usr/local version is to remove the /usr/local version which is why we tell users to do that. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
