Re: /usr/local question
On Apr 4, 2012, at 00:44, Jan Stary wrote: On Apr 03 17:54:05, saiwingy wrote: Since MacPorts is not compatible with /usr/local, every time I install/update ports I had to sudo mv /usr/local /usr/local.bak Why would you move /usr/local? Macports live under /opt/local by default and have nothing to do with /usr/local. Having things installed in /usr/local often interferes with MacPorts, so we do not support users using MacPorts while there are things in /usr/local, and suggest users move or remove /usr/local. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Shenidam
On Apr 3, 2012, at 15:15, Ryan Schmidt wrote: On Apr 3, 2012, at 14:44, Sam Kuper wrote: Is Shenidam a viable candidate for being ported into MacPorts? I'll see if I can make a port. I can't quite get it working. Here's what I've got so far: https://trac.macports.org/ticket/33891 If someone else can finish it I'd appreciate it. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
On Apr 3, 2012, at 8:40 PM, Ryan Schmidt wrote: On Apr 3, 2012, at 19:54, saiwingy wrote: Since MacPorts is not compatible with /usr/local, every time I install/update ports I had to sudo mv /usr/local /usr/local.bak and then after I am done building macports stuff I would move it back. This works fine but is kind of cumbersome and sometimes the moved /usr/local directory triggers a lot of mdutil activities. What do people do to automate this, or to make the process easier? Thanks! We don't install things in /usr/local. Why do you want to install things there? I don't install things there, but there are things in there (mostly from Mac OS) that I'd like to keep and use. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Shenidam
On 4 April 2012 07:45, Ryan Schmidt ryandes...@macports.org wrote: On Apr 3, 2012, at 15:15, Ryan Schmidt wrote: On Apr 3, 2012, at 14:44, Sam Kuper wrote: Is Shenidam a viable candidate for being ported into MacPorts? I'll see if I can make a port. I can't quite get it working. Here's what I've got so far: https://trac.macports.org/ticket/33891 If someone else can finish it I'd appreciate it. Thanks Ryan! I'll try to take a look at this later in the week. Not sure I'll be able to get any further than you did (I've much less expertise!) but it can't hurt to try :) Thanks again, Sam ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
Since MacPorts is not compatible with /usr/local, every time I install/update ports I had to sudo mv /usr/local /usr/local.bak Why would you move /usr/local? Macports live under /opt/local by default and have nothing to do with /usr/local. Having things installed in /usr/local often interferes with MacPorts, so we do not support users using MacPorts while there are things in /usr/local, and suggest users move or remove /usr/local. Remove /usr/local? I must have missed this in the documentation, can you point me please? I thought the whole reason for living under /opt/local was *not* to interfere with /usr/local. How exactly does having /usr/local interfere? Things from macports silently picking up things from /usr/local? Is that the problem? I don't install things there, but there are things in there (mostly from Mac OS) that I'd like to keep and use. Yes, I have things in /usr/local too - stuff that is _not_ in macports (otherwise I would just install it from macports - and have it installed under /opt/local), and local admin tools. It would be a PITA to make that disappear during every macports action (not that it's very often) ... ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
Hi, I don't install things there, but there are things in there (mostly from Mac OS) that I'd like to keep and use. I might be wrong but I understand OS X itself does not put anything in /usr/local. Anything you might have there has probably come from other third party applications you have installed, not the system itsdelf. Chris ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
Hi, I thought the whole reason for living under /opt/local was *not* to interfere with /usr/local. How exactly does having /usr/local interfere? Things from macports silently picking up things from /usr/local? Is that the problem? The issue is some packages have hard coded dependencies to look for things in /usr/local, and will use them if found. Most packages are developed on linux OSes, where /user/local is quite normal and thus they just consider this the 'right thing to do'... In principle packages should provide options to avoid this, and when they do MacPorts can use them, but not all do. I don't install things there, but there are things in there (mostly from Mac OS) that I'd like to keep and use. Yes, I have things in /usr/local too - stuff that is _not_ in macports (otherwise I would just install it from macports - and have it installed under /opt/local), and local admin tools. It would be a PITA to make that disappear during every macports action (not that it's very often) ... Perhaps the best advice is, if you find a package you need not in MacPorts, to build a port file for it and submit it for inclusion ;) Chris ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/04/2012 10:17, Chris Jones wrote: I thought the whole reason for living under /opt/local was *not* to interfere with /usr/local. How exactly does having /usr/local interfere? Things from macports silently picking up things from /usr/local? Is that the problem? The issue is some packages have hard coded dependencies to look for things in /usr/local, and will use them if found. Most packages are developed on linux OSes, where /user/local is quite normal and thus they just consider this the 'right thing to do'... In principle packages should provide options to avoid this, and when they do MacPorts can use them, but not all do. I don't install things there, but there are things in there (mostly from Mac OS) that I'd like to keep and use. Yes, I have things in /usr/local too - stuff that is _not_ in macports (otherwise I would just install it from macports - and have it installed under /opt/local), and local admin tools. It would be a PITA to make that disappear during every macports action (not that it's very often) ... Perhaps the best advice is, if you find a package you need not in MacPorts, to build a port file for it and submit it for inclusion ;) OS X's flavour of *nix is based on FreeBSD. Linux uses /usr/local /opt/local for users convenience for installing third-party software tries to make sure these directories are not overwritten by any vendor supplied software update. In theory you could make your yourself another directory under /usr call it whatever you like do exactly the same thing but unless you have a very reason for doing so know what you're doing, it's an ill advised idea. For the general purposes of safely installing the software you require for general upkeep of the health efficiency of your system, Mac Ports does a great job should be used as directed by its authors as was intended unless you have good reason not to. Just my two bob. Cheers, Phil... - -- But masters, remember that I am an ass. Though it be not written down, yet forget not that I am an ass. Wm. Shakespeare - Much Ado About Nothing -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: §auto-key-locate cert pka ldap hkp://keys.gnupg.net Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPfCDdAAoJEKpMeDHWT5ADgBkIALBKkZnS8ScQHxOGFsiIbVxA 2S/75pqKIr1WXXgXbU76RWLFC/3aCAvqo966CVvzeUqOzCEavxMNG+rTst0Ubpba 2EZ/7X5fgPE4zBDLhL0XYSlqtgTBlFaCd/AKxoOOPpAYONqjeZSWPTCRXpGnwYKK ryBIvwuafG044K0nzle5VyZAxdUYlRJcqySHRIWtA83uwdsWoZd+YzrkKWKZdPOu 7JVOxpSFSafi4xzdQgOZPzQYedr8TMispCi7eGW2bc//+pEPoZ8rSzLtIkyIMmIH jy79Bkn8RCGFRtMzUCaryxrz2U3EtBIjDEBT8wFWj8E0vFIwaO+9MYJay1+lmJg= =hqZ2 -END PGP SIGNATURE- ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
Le 04.04.12 08:38, Ryan Schmidt a écrit : Hello, The macport home directory is opt/local not usr/local Best regards mparchet On Apr 4, 2012, at 00:44, Jan Stary wrote: On Apr 03 17:54:05, saiwingy wrote: Since MacPorts is not compatible with /usr/local, every time I install/update ports I had to sudo mv /usr/local /usr/local.bak Why would you move /usr/local? Macports live under /opt/local by default and have nothing to do with /usr/local. Having things installed in /usr/local often interferes with MacPorts, so we do not support users using MacPorts while there are things in /usr/local, and suggest users move or remove /usr/local. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
On Wed, Apr 4, 2012 at 03:45, Saiwing Yeung saiw...@berkeley.edu wrote: On Apr 3, 2012, at 8:40 PM, Ryan Schmidt wrote: On Apr 3, 2012, at 19:54, saiwingy wrote: Since MacPorts is not compatible with /usr/local, every time I install/update We don't install things in /usr/local. Why do you want to install things there? I don't install things there, but there are things in there (mostly from Mac OS) that I'd like to keep and use. Apple doesn't install anything under /usr/local; it can only come from third party stuff. -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
On Apr 04 10:17:23, Chris Jones wrote: Hi, I thought the whole reason for living under /opt/local was *not* to interfere with /usr/local. How exactly does having /usr/local interfere? Things from macports silently picking up things from /usr/local? Is that the problem? The issue is some packages have hard coded dependencies to look for things in /usr/local, and will use them if found. Yes. Most packages are developed on linux OSes, where /user/local is quite normal and thus they just consider this the 'right thing to do'... In principle packages should provide options to avoid this, and when they do MacPorts can use them, but not all do. Isn't that a task of the port maintainer then to patch such a software so that any interference with /usr/local can be avoided? I just find it quite extreme to expect the user to not have /usr/local around. The reason macports uses /opt/local (if I am not wrong) is that macports realizes that people *do* have /usr/local around. I don't install things there, but there are things in there (mostly from Mac OS) that I'd like to keep and use. I don't think that MacOS itself installs anything under /usr/local Yes, I have things in /usr/local too - stuff that is _not_ in macports (otherwise I would just install it from macports - and have it installed under /opt/local), and local admin tools. It would be a PITA to make that disappear during every macports action (not that it's very often) ... Perhaps the best advice is, if you find a package you need not in MacPorts, to build a port file for it and submit it for inclusion ;) Agreed. I try to create ports for thing that I miss. But sometimes I just install from the vanilla targzip, if only for the intermediate tome before I get to creating a macport for it :-) Jan ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
On Apr 4, 2012, at 10:51 AM, Jan Stary wrote: Most packages are developed on linux OSes, where /user/local is quite normal and thus they just consider this the 'right thing to do'... In principle packages should provide options to avoid this, and when they do MacPorts can use them, but not all do. Isn't that a task of the port maintainer then to patch such a software so that any interference with /usr/local can be avoided? the problem lies with the apple-supplied complier toolchain, there is no 'good' solution to the issue. (there are several things that might work, or could work, but no one of the volunteers who maintain MacPorts has tried implementing any of them as far as I know) I just find it quite extreme to expect the user to not have /usr/local around. The reason macports uses /opt/local (if I am not wrong) is that macports realizes that people *do* have /usr/local around. I, personally, have had /usr/local around for forever. The issue is that if you don't know it can interfere (and can't diagnose and fix any instances when it does), it's very difficult to help you if/when you have problems. So, the 'safe' advice we give people is don't do that Agreed. I try to create ports for thing that I miss. But sometimes I just install from the vanilla targzip, if only for the intermediate tome before I get to creating a macport for it :-) For me, the biggest reason to buy into always creating ports for things that I need that aren't in macports is the ease with which I can _uninstall_ the software if/when I no longer want it (easy upgrading is a plus too, but of course I started using macports before it could upgrade software ;-) ). -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
I just find it quite extreme to expect the user to not have /usr/local around. The reason macports uses /opt/local (if I am not wrong) is that macports realizes that people *do* have /usr/local around. I, personally, have had /usr/local around for forever. The issue is that if you don't know it can interfere (and can't diagnose and fix any instances when it does), it's very difficult to help you if/when you have problems. So, the 'safe' advice we give people is don't do that OK, I can understand that. Did I really miss this bit in the documentation? Can someone point me please? I believe it should be clearly stated in the Guide. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
OK, I can understand that. Did I really miss this bit in the documentation? Can someone point me please? I believe it should be clearly stated in the Guide. It is not in the Guide, however the FAQ wiki page references it: https://trac.macports.org/wiki/FAQ#defaultprefix smime.p7s Description: S/MIME cryptographic signature ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
On Apr 04 10:22:37, Jeremy Lavergne wrote: OK, I can understand that. Did I really miss this bit in the documentation? Can someone point me please? I believe it should be clearly stated in the Guide. It is not in the Guide, however the FAQ wiki page references it: https://trac.macports.org/wiki/FAQ#defaultprefix Yes, that's what I have read. But that just says why macports uses /opt/local: because it cannot use /usr/local, for the reasons listed. This here is something *different*: namely, that (1) There might still be problems if the user has /usr/local around. (2) So the user should not have /usr/local around None of that is mentioned at the above link. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
Yes, that's what I have read. But that just says why macports uses /opt/local: because it cannot use /usr/local, for the reasons listed. This here is something *different*: namely, that (1) There might still be problems if the user has /usr/local around. • Some software (especially auto* tools from Gnu) look in /usr/local as a default location • /usr/local tends to be a bad choice to have taken over by a non-system port system • gcc considers /usr/local to be a standard system directory, causing (at least) the include directory to be unable to appear early in the list of include directories, and hence causing MacPorts-installed items to be difficult to use properly for items which need them (where another version is installed elsewhere, like/usr/X11R6) (2) So the user should not have /usr/local around None of that is mentioned at the above link. It isn't explicitly stated but it is implied. smime.p7s Description: S/MIME cryptographic signature ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
On Apr 04 10:34:48, Jeremy Lavergne wrote: Yes, that's what I have read. But that just says why macports uses /opt/local: because it cannot use /usr/local, for the reasons listed. This here is something *different*: namely, that (1) There might still be problems if the user has /usr/local around. ? Some software (especially auto* tools from Gnu) look in /usr/local as a default location ? /usr/local tends to be a bad choice to have taken over by a non-system port system ? gcc considers /usr/local to be a standard system directory, causing (at least) the include directory to be unable to appear early in the list of include directories, and hence causing MacPorts-installed items to be difficult to use properly for items which need them (where another version is installed elsewhere, like/usr/X11R6) Yes; I _have_ read it. The FAQ lists these as the reasons why macports uses /opt/local as its prefix. Perhaps I need to state my comment more explicitly: there are TWO DIFFERENT issues: (1) It would be a problem if macports used /usr/local as its prefix; so it doesn't - it uses /opt/local instead (2) Even with macports using /opt/local as its prefix, it is STILL A PROBLEM to have /usr/local around. The link above talks about (1), but not (2). It isn't explicitly stated but it is implied. No it's not; on the contrary, it is implied that using the prefix of /opt/local instead of /usr/local SOLVES the three issues listed above, which it does not. In fact, I believe it is a good candidate for a FAQ immediately following https://trac.macports.org/wiki/FAQ#defaultprefix: Q: So given that macports uses /opt/local as its prefix, I can use /usr/local freely without worying about interference? A: No, not really. (etc) ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
oh... I didn't know that. I just took a look in my /usr/local, and found a whole bunch of stuff for texlive, and then various programs that I remember installing. is there a recommended place for me to put these programs? On Apr 4, 2012, at 2:12 AM, Chris Jones wrote: Hi, I don't install things there, but there are things in there (mostly from Mac OS) that I'd like to keep and use. I might be wrong but I understand OS X itself does not put anything in /usr/local. Anything you might have there has probably come from other third party applications you have installed, not the system itsdelf. Chris ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
On Apr 4, 2012, at 10:55, Jan Stary wrote: In fact, I believe it is a good candidate for a FAQ immediately following https://trac.macports.org/wiki/FAQ#defaultprefix: Q: So given that macports uses /opt/local as its prefix, I can use /usr/local freely without worying about interference? A: No, not really. (etc) The wiki is editable by everybody; feel free to add this. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
On Apr 4, 2012, at 11:16, Saiwing Yeung wrote: oh... I didn't know that. I just took a look in my /usr/local, and found a whole bunch of stuff for texlive, and then various programs that I remember installing. is there a recommended place for me to put these programs? Any other place on the hard drive that doesn't already have a defined meaning. So any prefix other than /, /usr, /usr/local, /opt/local or /sw should be fine. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
On Apr 4, 2012, at 9:55 AM, Jan Stary wrote: Q: So given that macports uses /opt/local as its prefix, I can use /usr/local freely without worying about interference? A: No, not really. (etc) I'd really like to see an expansion of that etc. I use Linux extensively for my servers and Macs when I'm trying to be a human. /usr/local has been around for quite a while in the *nix world (it's even in the default $PATH), and I use it a little on the Macs. I can't think of what the problem is -- (seems to) work fine here :-) -- Glenn English ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
I use Linux extensively for my servers and Macs when I'm trying to be a human. /usr/local has been around for quite a while in the *nix world (it's even in the default $PATH), and I use it a little on the Macs. I can't think of what the problem is -- (seems to) work fine here :-) I don't see /usr/local in my system's default for $PATH, either on 10.6 or 10.7. /usr/local is horrible because it takes precedence over everything else on your system. As was pointed out: * some software (especially auto* tools from Gnu) look in /usr/local as a default location * gcc considers /usr/local to be a standard system directory, causing (at least) the include directory to be unable to appear early in the list of include directories, and hence causing MacPorts-installed items to be difficult to use properly for items which need them (where another version is installed elsewhere, like/usr/X11R6) This means incorrect libraries and headers that magically find their way in there via other installers will be used instead of the software that was actually intended. Incompatible software (e.g. ppc on x86_64) might be installed there and you can see why that would break things. smime.p7s Description: S/MIME cryptographic signature ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
On Apr 4, 2012, at 11:20, Glenn English wrote: On Apr 4, 2012, at 9:55 AM, Jan Stary wrote: Q: So given that macports uses /opt/local as its prefix, I can use /usr/local freely without worying about interference? A: No, not really. (etc) I'd really like to see an expansion of that etc. I use Linux extensively for my servers and Macs when I'm trying to be a human. /usr/local has been around for quite a while in the *nix world (it's even in the default $PATH), and I use it a little on the Macs. I can't think of what the problem is -- (seems to) work fine here :-) Because /usr/local is searched by default by the compiler and we do not know how to turn that off, MacPorts ports might try to link with libraries you've installed in /usr/local. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
On Apr 4, 2012, at 10:26 AM, Jeremy Lavergne wrote: I don't see /usr/local in my system's default for $PATH, either on 10.6 or 10.7. Sorry. Maybe I should have said, the default *nix $PATH. I don't know about others. OTOH, here's my user $PATH on 10.7.3: /usr/local/bin:/usr/bin:/bin:/usr/games. I'd always assumed that MacPorts put itself in /opt/local so there wouldn't be a problem with libs and bins that had the same names on the *nix systems they were originally written for. I thought that was very clever of them. -- Glenn English ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
On Apr 4, 2012, at 9:19 AM, Ryan Schmidt wrote: On Apr 4, 2012, at 11:16, Saiwing Yeung wrote: oh... I didn't know that. I just took a look in my /usr/local, and found a whole bunch of stuff for texlive, and then various programs that I remember installing. is there a recommended place for me to put these programs? Any other place on the hard drive that doesn't already have a defined meaning. So any prefix other than /, /usr, /usr/local, /opt/local or /sw should be fine. Thanks! In addition, I agree with Jan Stary that it would be nice to amend the #defaultprefix: section in the FAQ. If possible, it would also be nice to also add this to the A port fails to build. What should I do? section in the FAQ, as the section title of #defaultprefix is Why is /opt/local the default install location for MacPorts? and if a port fails to build for me, I probably wouldn't realize that pertinent information is in that section. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
On 04/04/2012 06:26 PM, Jeremy Lavergne wrote: I use Linux extensively for my servers and Macs when I'm trying to be a human. /usr/local has been around for quite a while in the *nix world (it's even in the default $PATH), and I use it a little on the Macs. I can't think of what the problem is -- (seems to) work fine here :-) I don't see /usr/local in my system's default for $PATH, either on 10.6 or 10.7. /usr/local should be listed in /etc/paths and thus, would be in your default $PATH. I don't think anything changed on that in any recent Mac OS X release. I guess you removed it yourself on purpose? Rainer ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
On Apr 4, 2012, at 10:27 AM, Ryan Schmidt wrote: Because /usr/local is searched by default by the compiler and we do not know how to turn that off, MacPorts ports might try to link with libraries you've installed in /usr/local. Ah! Thank you; that makes sense. I'll try to stay away from installing libraries there. I just looked, and all that's in mine is perl, python, and ruby -- I'll also keep in mind your explanation when something goes odd with a MacPorts build. Is that default search part of the compiler code, or is it because of $PATH? If Apple doesn't use /usr/local libraries, why would they have anything to do with a compiler that forces that search? That'd result in a lot on badly bent code lying around. This might be overkill, but have you considered adding code to your scripts to mv /usr/local to /usr/localqw (and back at the end)? Or maybe just the lib dir? -- Glenn English ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
On Apr 4, 2012, at 12:42, Glenn English wrote:
On Apr 4, 2012, at 10:27 AM, Ryan Schmidt wrote:
Because /usr/local is searched by default by the compiler and we do not know
how to turn that off, MacPorts ports might try to link with libraries you've
installed in /usr/local.
Ah! Thank you; that makes sense. I'll try to stay away from installing
libraries there.
I just looked, and all that's in mine is perl, python, and ruby -- I'll also
keep in mind your explanation when something goes odd with a MacPorts build.
Is that default search part of the compiler code, or is it because of $PATH?
It is code in the compiler. It's not related to $PATH.
If Apple doesn't use /usr/local libraries, why would they have anything to do
with a compiler that forces that search? That'd result in a lot on badly bent
code lying around.
The definition of /usr/local is a directory where users put things they've
compiled themselves; things that did not come from the OS vendor. Therefore it
is right for Apple to not ship anything in /usr/local, and it's perhaps even
reasonable for them to ship a compiler that looks there for dependencies. I
didn't think this was an Apple-specific thing; I thought that's just how GCC
works, but I don't know for sure.
This might be overkill, but have you considered adding code to your scripts
to mv /usr/local to /usr/localqw (and back at the end)? Or maybe just the lib
dir?
I had not considered that. But MacPorts is not always installed as root; when
not root, it would not have permission to do that. Also, moving /usr/local is
likely to break whatever's installed there. I think the user needs to be the
one to understand the consequences of their actions of installing things in
/usr/local and be the one to take responsibility for uninstalling those items.
Not everything in /usr/local is necessarily a problem. But we do not want to
spend our time analyzing what rogue software is and isn't a problem; we have
real actual MacPorts issues that we want to spend our time solving that don't
involve rogue software. If a user reports a problem, and the error message or
log contents point to something existing in /usr/local, our response will be to
make the user remove /usr/local and try again.
I might not be opposed to MacPorts printing a warning if anything is found in
/usr/local/{bin,etc,include,lib,libexec,man,sbin,share,var}. But I would
probably only want to print that if a port actually failed to build.
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/04/2012 18:30, Saiwing Yeung wrote: On Apr 4, 2012, at 9:19 AM, Ryan Schmidt wrote: On Apr 4, 2012, at 11:16, Saiwing Yeung wrote: oh... I didn't know that. I just took a look in my /usr/local, and found a whole bunch of stuff for texlive, and then various programs that I remember installing. is there a recommended place for me to put these programs? Any other place on the hard drive that doesn't already have a defined meaning. So any prefix other than /, /usr, /usr/local, /opt/local or /sw should be fine. Thanks! In addition, I agree with Jan Stary that it would be nice to amend the #defaultprefix: section in the FAQ. If possible, it would also be nice to also add this to the A port fails to build. What should I do? section in the FAQ, as the section title of #defaultprefix is Why is /opt/local the default install location for MacPorts? and if a port fails to build for me, I probably wouldn't realize that pertinent information is in that section. If you want to install in directories other than /usr/local to avoid any conflicts with Mac Ports, you could use the other *nix location $HOME/bin. On most, if not all, Linux distros that PATH is already present in ~/.bashrc. You'd probably have to create the directory in /Users/yourname as well as add the above line to your bash_profile but I use $HOME/bin a lot on OS X Linux. It also has the added advantage of not having to use sudo when installing stuff. Cheers, Phil... - -- But masters, remember that I am an ass. Though it be not written down, yet forget not that I am an ass. Wm. Shakespeare - Much Ado About Nothing -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: §auto-key-locate cert pka ldap hkp://keys.gnupg.net Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPfJW2AAoJEKpMeDHWT5AD/iAIAIVHGason4hfmufPOKocPpMI M1A+Bx8M3GjnMXr75nhC4mYA8h+t5Qh8tbMido5Rtne4CVazpynCPp6CA4N4nUBF iKgiiRP1Ab/+Erl1+rFVsELAtsxWvTI1VSFi/quwUJpNiFLwsS6PG37fcCfUV6uC D9KhFhcgUNz7SEhEvfQlTZXw35CEAOXX8uZNP6SAPEAZ8nSoHe0HsQg8ee3lWa7O VALRvhSXRDdXS29GMugY7/ERLNo35ooNGpz5lgIxOEV3Gjs+41gPtBw8GeC9P3uH ohBiwHEYrkTuRaCBDz7cym/I4uhkRmfaIfHf8sumvAwETY9T3UpE7Q3LQRI6mgg= =FwLK -END PGP SIGNATURE- ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/04/2012 19:40, Phil Dobbin wrote: On 04/04/2012 18:30, Saiwing Yeung wrote: On Apr 4, 2012, at 9:19 AM, Ryan Schmidt wrote: On Apr 4, 2012, at 11:16, Saiwing Yeung wrote: oh... I didn't know that. I just took a look in my /usr/local, and found a whole bunch of stuff for texlive, and then various programs that I remember installing. is there a recommended place for me to put these programs? Any other place on the hard drive that doesn't already have a defined meaning. So any prefix other than /, /usr, /usr/local, /opt/local or /sw should be fine. Thanks! In addition, I agree with Jan Stary that it would be nice to amend the #defaultprefix: section in the FAQ. If possible, it would also be nice to also add this to the A port fails to build. What should I do? section in the FAQ, as the section title of #defaultprefix is Why is /opt/local the default install location for MacPorts? and if a port fails to build for me, I probably wouldn't realize that pertinent information is in that section. If you want to install in directories other than /usr/local to avoid any conflicts with Mac Ports, you could use the other *nix location $HOME/bin. On most, if not all, Linux distros that PATH is already present in ~/.bashrc. You'd probably have to create the directory in /Users/yourname as well as add the above line to your bash_profile but I use $HOME/bin a lot on OS X Linux. It also has the added advantage of not having to use sudo when installing stuff. the above (non-existent) line of course being: `PATH=$PATH:$HOME/bin` :-) - -- But masters, remember that I am an ass. Though it be not written down, yet forget not that I am an ass. Wm. Shakespeare - Much Ado About Nothing -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: §auto-key-locate cert pka ldap hkp://keys.gnupg.net Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPfJaEAAoJEKpMeDHWT5ADxUcIAJXB53+Kh0Pqweu2TJcwdJYS Yko/t3Bg2cnfT7QZQ0+ZzVulmU5UUsQ7TkgU4b4alVzTDwzyePsU/bGe+DTGLAjZ jH40FgQz8Bf1odJE7akSzPc3QGpF+BfpU0OOVC+nZ5JKb10nt+GG8KDU3EEZVhEH KH0Pq6u03VeKv1cLFaUQa3Do8cjas9tbRcZEMirykKV7i5r5Vu8uj6bqraA/yHyD dWKoE7yHROLRtkwfdur6kiqA2+V2UZCkwGcuxCOnGPJ6ERc1dSrhlr2AKTGmx9LZ u6NBSYN1FDjVTwCjBASfplzc4F0f2ZASPJMcVbyOEe0Rdb7aAZvoYGPloDwki8U= =Jh6Q -END PGP SIGNATURE- ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
How to run a sql script sql script on mysql5
Hello, I have install the mysql5 port. I do a secure installation whith only the root user and a password. So noe I wold like to run a sql script to create a database. I have tried the following command but this last has no effect sudo mysql5 -u root -p password script.sql Can you help me please ? Best regards mparchet ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: How to run a sql script sql script on mysql5
On Apr 4, 2012, at 12:14 PM, Michael Parchet wrote: Hello, I have install the mysql5 port. I do a secure installation whith only the root user and a password. So noe I wold like to run a sql script to create a database. I have tried the following command but this last has no effect sudo mysql5 -u root -p password script.sql Can you help me please ? You should probably take this to a mysql support forum. I do this: $ mysql5 -uroot -p mysql create database mydb; mysql use mydb; mysql system ls; mysql source script.sql; mysql show tables; mysql exit; Your script.sql file may well create a database or has a use dbname statement at the top. http://dev.mysql.com/doc/refman/5.0/en/batch-commands.html Regards, Bradley Giesbrecht (pixilla) smime.p7s Description: S/MIME cryptographic signature ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: How to run a sql script sql script on mysql5
On Apr 4, 2012, at 3:14 p.m., Michael Parchet wrote: I have install the mysql5 port. I do a secure installation whith only the root user and a password. So noe I wold like to run a sql script to create a database. Are you making a local database? Have you installed mysql5-server? vq ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: How to run a sql script sql script on mysql5
Le 04.04.12 21:37, Lawrence Velázquez a écrit : On Apr 4, 2012, at 3:14 p.m., Michael Parchet wrote: I have install the mysql5 port. I do a secure installation whith only the root user and a password. So noe I wold like to run a sql script to create a database. Are you making a local database? Have you installed mysql5-server? Yes ouf course. vq ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
I might not be opposed to MacPorts printing a warning if anything is found in
/usr/local/{bin,etc,include,lib,libexec,man,sbin,share,var}. But I would
probably only want to print that if a port actually failed to build.
It sounds very reasonable to check if there's anything in /usr/local when a
build fails, and then add the error message suggesting the user temporarily
move /usr/local, clean the broken port (not necessarily the one they were
installing) and make again.
smime.p7s
Description: S/MIME cryptographic signature
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
The more I think about it, the more I tend to this conclusion: Using /opt/local as the default prefix is an attempt to save the user from himself, which is pointless. Any other benefits it has would also be present if the default prefix was /usr/local. Please bare with me and wait with the stoning. First, let me go through the reasons we currently do NOT use /usr/local as the default prefix, as described in the FAQ: (1) /opt/local was chosen so as to avoid stomping on other various installations What other various installations, exactly? Nobody uses more then one port system on a given machine (not that know about any other beside macports and fink). So whatever the macports prefix, it will not stomp on any other port system's installations (or vice versa), because there is no other port system in use. That leaves - the MacOS isntallation as shipped by Apple - manual installations done by the user As agreed before, MacOSX itself doesn't install nothing under /usr/local. That leaves only the user manually installing stuff under /usr/local (as usual on many UNIXes). The only way these installations would stomp on each other is if the user either installs something from macports and later overwrites it with a manual installation, or vice versa. That's the user's obvious and stupid error. Retreating from /usr/local in the sense of (1) is nothing else than trying to protect the user from himself. I think that't pointless. (2) /usr/local is not a viable choice because some software (especially auto* tools from Gnu) look in /usr/local as a default location, which means MacPorts can't be easily isolated when needed. I want to kindly ask the person who wrote this to elaborate, and be as specific as can be: what exactly does it mean for macports to be isolated, and how exactly does e.g. auto* looking into /usr/local stand in the way of it? Does the isolation here mean that the libraries, headers, etc as installed from macports should be distinguishable by third-party software as such (i.e., as installed by macports, and no other)? Indeed, the auto* tools and other software (gcc?) look into /usr/local. That's not a reason to NOT install our stuf in there. On the contrary, that's a reason to install in there, as ubiquitous tools such as auto* and pkgconfig and gcc WILL FIND IT THERE when installing other software later. In fact, that's one of the reasons people do install software: so that it is found and used by other software. Example: if, say, libsndfile is installed under /usr/local, compiling any other audio software later will find it there BY DEFAULT and use it, WHICH IS WHY I installed it in the first place. (3) /usr/local is not a viable choice because it is usually reserved for the given system's admin to install items local to that system, and tends to be a bad choice to have taken over by a non-system port system. Yes, /usr/local i traditionaly used to install items local to that system. How does it make it a bad choice for the macports prefix? The stuff I install from macports IS local to that system! Also, it's not macports taking over /usr/local. The user takes over /usr/local (as intended for ages), be it via manual installation or macports or anything else. (4) /usr/local is not a viable choice because gcc considers /usr/local to be a standard system directory, causing (at least) the include directory to be unable to appear early in the list of include directories, and hence causing MacPorts-installed items to be difficult to use properly for items which need them (where another version is installed elsewhere, like /usr/X11R6) Yes, gcc considers /usr/local to be a standard directory; it is searched for headers and libs and binaries. How does that make the include directory (which? /usr/local/include?) not able to appear early in the list of include directories? On the contrary, being considered a standard system directory, it appers in the list prominently. If macports installed stuff under /usr/local, how exactly would make it difficult to be used properly? On Apr 04 11:26:14, Jeremy Lavergne wrote: /usr/local is horrible because it takes precedence over everything else on your system Yes, it takes precedence. That's the point: to have a place where things are supposed to be installed. Why does it make /usr/local horrible? How would that be less horrible if it was any other directory? This means incorrect libraries and headers that magically find their way in there via other installers will be used instead of the software that was actually intended. Whoa, stop right there. This paragraph makes no argument against /usr/local, it's just dissing it with meanlessly negative adjectives. (*) What incorrect libraries and headers? The headers and libraries I install under /usr/local (or anywhere else, for that matter) manually (or any other way, for that matter) are no more or less correct than those installed by macports (or any other installer, for that matter). (*)
Re: /usr/local question
/usr/local is not a viable choice because some software (especially auto* tools from Gnu) look in /usr/local as a default location, which means MacPorts can't be easily isolated when needed. I want to kindly ask the person who wrote this to elaborate, and be as specific as can be: what exactly does it mean for macports to be isolated, and how exactly does e.g. auto* looking into /usr/local stand in the way of it? As with the software that magically found its way into /usr/local, how do we stop that very same software from clobbering what MacPorts has installed there? smime.p7s Description: S/MIME cryptographic signature ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/04/2012 22:01, Jan Stary wrote: [...] You'd probably have to create the directory in /Users/yourname Huh? That's my $HOME, which obviously exists already. I was referring to the /bin directory not $HOME `PATH=$PATH:$HOME/bin` That puts it last in the path, which is probably not what you intended. Your logic there defeats me... Cheers, Phil. - -- But masters, remember that I am an ass. Though it be not written down, yet forget not that I am an ass. Wm. Shakespeare - Much Ado About Nothing -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: §auto-key-locate cert pka ldap hkp://keys.gnupg.net Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPfLjLAAoJEKpMeDHWT5ADplYH/1TaFBx2K2TYvk0KvF1vbmLO jgt+K8wsOHErJgMcv3IOS8I86kANKfqs/jaTEx4H0CseohK1MrhU0avo/nnpX9+m uSWdAZMIWsEcozmGrYoxQXdkG/1MMalhpPcF8hMc8KHCjvmL5j9GcQsxdnT6MMgO GMQl/xAzXN5Z1/suQH8T8HlhzR7FJ+eY1cvOXtbslpeQp+N5LhZ8BCacdYyRVBYH DKuz9JREfyhSiLNGBvmNlDBvxQlrdtpAQdrusShxBZRRXN/W6Gq+y9yT6w3O3s6z kmphrmIKSV4msgab3FYzThxJ45mv+2K4epdp61Ps8nNWtJxdz9dRtAldJYTCA3Y= =uSUb -END PGP SIGNATURE- ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
`PATH=$PATH:$HOME/bin` That puts it last in the path, which is probably not what you intended. Your logic there defeats me... Just standard concatenation: it was appended at the end. This doesn't much matter though, since the original thread has nothing to do with $PATH. smime.p7s Description: S/MIME cryptographic signature ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/04/2012 22:15, Jeremy Lavergne wrote: `PATH=$PATH:$HOME/bin` That puts it last in the path, which is probably not what you intended. Your logic there defeats me... Just standard concatenation: it was appended at the end. This doesn't much matter though, since the original thread has nothing to do with $PATH. Ah, I was just using it as an example of the Linux entry in bashrc. Cheers, Phil... - -- But masters, remember that I am an ass. Though it be not written down, yet forget not that I am an ass. Wm. Shakespeare - Much Ado About Nothing -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: §auto-key-locate cert pka ldap hkp://keys.gnupg.net Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPfLrXAAoJEKpMeDHWT5ADqSsIAJZ9YnH/QQGDbJvkCJ3g2YC9 tXuTXbILZzzwPDbilDSPz939D/KQHAbcdNuvbp3nrN5MaqfLv9j0g7UcSRIitgIS pPN51JSHnXcttcaPFpR54Au/xXoKFX+FAES4UnaQftD20QbFStM1DCMjJiq4v9DM kccuqSJE9Y9fEz9mvJxHoGBP9NSbs9ofRNwDl5eYSLm0h1c0k7n0bNlhZveH2m66 X/qfhUfF/bvgX/DnTqDsqvOy0uHbVw5XQLA+r/5NSWcrG4okd9Tm7FtT3sh7S3Tw ormyEUu1OrZlwrnMQ2PLWH8q6CYfnBvvKLDy9tywhcoOx87Dj9JufE7sgzLJZDc= =gV7o -END PGP SIGNATURE- ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
On Apr 04 16:05:27, Jeremy Lavergne wrote: /usr/local is not a viable choice because some software (especially auto* tools from Gnu) look in /usr/local as a default location, which means MacPorts can't be easily isolated when needed. I want to kindly ask the person who wrote this to elaborate, and be as specific as can be: what exactly does it mean for macports to be isolated, and how exactly does e.g. auto* looking into /usr/local stand in the way of it? As with the software that magically found its way into /usr/local, how do we stop that very same software from clobbering what MacPorts has installed there? You keep saying that: the software that magically finds its way to /usr/local. What do you even mean by that? The user installed it there; that's about the only way something gets into /usr/local. And how do we stop the user from rewriting something that is already there? We don't, and we can't. It's the user's responsibility to not be an idiot and rewrite something he has installed himself before. In fact, what difference does /usr/local or /opt/local (or any ther prefix for that matter) make in this respect? In the current state of things, how do you stop the user from overwriting something that macports has installed under /opt/local? You don't, because you can't. It's the user's responsibility to not install over something that is already installed (whatever the prefix is). ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
On Apr 4, 2012, at 5:01 PM, Jan Stary wrote: What other various installations, exactly? Nobody uses more then one port system on a given machine (not that know about any other beside macports and fink). So whatever the macports prefix, it will not stomp on any other port system's installations (or vice versa), because there is no other port system in use. That leaves - the MacOS isntallation as shipped by Apple - manual installations done by the user I have at times installed both fink and macports on the same system, although I always move one of them aside (e.g., mv /sw /sw-save) before using the other. It's nice to be able to check that my software will build against either macports or fink before distributing it to users. Having all macports files sequestered in their own directory is extremely useful. Aside from that objection, I agree with most of your points. It's not feasible to expect that every package is available in macports. Whether you like it or not, sometimes people will have to install something that hasn't been ported. If they want to install it in a system-wide directory, so that it's easily used by many users, /usr/local is the obvious place to put it. There isn't a problem unless they install something in /usr/local that's also provided (in an incompatible version) by macports. That should be the users job to ensure. Macports should warn the user about that, but imposing a blanket ban on /usr/local is a bad idea. Perhaps this is the right place to think Jeremy and Ryan and the others for making macports happen in the first place. I agree with that, too. Thanks! -- Steve -- -- EMail: stephen.lan...@nist.govPhone: (301) 975-5423 -- -- http://math.nist.gov/~SLanger/ Fax: (301) 975-3553 -- -- Mail: NIST; 100 Bureau Drive -- Stop 8910; Gaithersburg, Md 20899-8910 -- -- I don't think this will work. That's why it's science. -- -- Naomi Langer (age 6), 17 Feb 2003 -- ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
You keep saying that: the software that magically finds its way to /usr/local. What do you even mean by that? The user installed it there; that's about the only way something gets into /usr/local. The user is typically unaware of where packaged software is installed. You can look at our mounds of trouble tickets that were caused by this specific reason. The user simply ran some installer program, and magic happened. And how do we stop the user from rewriting something that is already there? We don't, and we can't. It's the user's responsibility to not be an idiot and rewrite something he has installed himself before. That is a reason why we shouldn't use /usr/local: users are less to ran an installer that clobbers inside MacPorts-specific directories. In fact, what difference does /usr/local or /opt/local (or any ther prefix for that matter) make in this respect? In the current state of things, how do you stop the user from overwriting something that macports has installed under /opt/local? There is a huge difference between: * the user explicitly running a command to overwrite MacPorts, and * the user ran an installer that did something somewhere. When the user runs an installer program, chances are it won't install to /opt/local but instead install to /usr/local or /Library. Since /usr/local is a prime target, it would be very likely that users routinely overwrite MacPorts on accident. You don't, because you can't. It's the user's responsibility to not install over something that is already installed (whatever the prefix is). If only all OS X users could know what they were doing. smime.p7s Description: S/MIME cryptographic signature ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
On 04.04.2012, at 23:20, Jan Stary wrote: On Apr 04 16:05:27, Jeremy Lavergne wrote: /usr/local is not a viable choice because some software (especially auto* tools from Gnu) look in /usr/local as a default location, which means MacPorts can't be easily isolated when needed. I want to kindly ask the person who wrote this to elaborate, and be as specific as can be: what exactly does it mean for macports to be isolated, and how exactly does e.g. auto* looking into /usr/local stand in the way of it? As with the software that magically found its way into /usr/local, how do we stop that very same software from clobbering what MacPorts has installed there? You keep saying that: the software that magically finds its way to /usr/local. What do you even mean by that? The user installed it there; that's about the only way something gets into /usr/local. And how do we stop the user from rewriting something that is already there? We don't, and we can't. It's the user's responsibility to not be an idiot and rewrite something he has installed himself before. In fact, what difference does /usr/local or /opt/local (or any ther prefix for that matter) make in this respect? In the current state of things, how do you stop the user from overwriting something that macports has installed under /opt/local? You don't, because you can't. It's the user's responsibility to not install over something that is already installed (whatever the prefix is). All kinds of software do actually install their stuff in /usr/local on OS X. Examples are a libpng framework from http://ethan.tira-thompson.com/Mac_OS_X_Ports.html or the Sane packages you get through following the links on the official sane site (that's the two things that *magically* ended up in my /usr/local). The problem is that a couple of packages just install to /usr/local without explicitly stating that or giving the option to use another prefix. This is something you can't avoid and would mess up MacPorts if it were to use /usr/local (the index of installed ports would no longer match what is *really* there because some software overwrites the existing libs and includes - making it worse by not honoring what the macports user wanted if he chose universal builds, etc...). Not many packages will use /opt/local, the few that do seem to be by rookie packagers that used a MacPorts base to build their package. Never encountered one of those yet. So in the above example this can mess up MacPorts builds when a port relies on libpng and wants the up to date libpng but is forced to use whatever version that is installed in /usr/local because the compiler defaults to that one. Alltogether I wonder what your aim is anyway, you won't change the developers decision to change the prefix after years of using that. Dom ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
Too many outright errors. Please. On Wed, Apr 4, 2012 at 17:01, Jan Stary h...@stare.cz wrote: /opt/local was chosen so as to avoid stomping on other various installations What other various installations, exactly? Any software not part of a package system such as Apple's own, Fink, MacPorts, Homebrew, etc. A highly incomplete ist of specific examples: - Growl extensions (specifically growlnotify installs there) - The official Haskell Platform installer - The official TeXLive installer It's the usual Unixy place for third party software, a point you yourself made at some point; how is it you are now unaware of it? Nobody uses more then one port system on a given machine Excuse me? Conflicts between the various installer systems happen fairly often, because people *do* try to use multiple installer systems --- as well as third party software independent of them (as above). /usr/local is not a viable choice because some software (especially auto* tools from Gnu) look in /usr/local as a default location, which means MacPorts can't be easily isolated when needed. I want to kindly ask the person who wrote this to elaborate, and be as specific as can be: what exactly does it mean for macports to be isolated, and how exactly does e.g. auto* looking into /usr/local stand in the way of it? So, are you at all familiar with the concept of repeatable builds? It is something which has particular importance in the world of packaging systems: it means, among other things, that you can ensure that a package builds the same way and runs the same way on as many systems as possible. MacPorts would not be particularly useful if a port only built properly on its maintainer's machine. Isolation of the package system is part of what makes this possible. /usr/local is not a viable choice because it is usually reserved for the given system's admin to install items local to that system, and tends to be a bad choice to have taken over by a non-system port system. Yes, /usr/local i traditionaly used to install items local to that system. How does it make it a bad choice for the macports prefix? The stuff I install from macports IS local to that system! By that same argument, installing anything via apt-get or yum on Linux should install to /usr/local because you're only installing it locally. You are misunderstanding the point here completely. /usr/local is specifically intended to be left alone by *any* package system. This includes MacPorts. This means incorrect libraries and headers that magically find their way in there via other installers will be used instead of the software that was actually intended. Whoa, stop right there. This paragraph makes no argument against /usr/local, it's just dissing it with meanlessly negative adjectives. If you still believe this, reread my previous statements until you understand them. The definition of /usr/local is a directory where users put things they've compiled themselves; things that did not come from the OS vendor. EXACTLY - such as the macports stuff! That's what I have compiled myself (with the help of a Portfile); that's what did not come from the OS vendor. See? You have lost track of MacPorts being a package system. If you built it yourself, not as part of a package system, that's what /usr/local is for. No package system should be touching /usr/local. Again, this is just bad-mouthing. Why would anything under /usr/local (or anything outside of macports) BE a problem, solely on the grounds it is under /usr/local? Really? What rogue software? ...and the fact that you keep repeating this indicates to me that you are not at all experienced in the concept of packaging, or package systems. You know about your own machine, you only care about your own machine; this is fine for you, but you fail to understand that the restrictions MacPorts operates under ensure that it will work on your machine instead of just the port maintainer's machine. Ironically, making the changes you claim are the only way that makes sense would probably result in MacPorts being unusable for you. (I am, by the way, seriously considering saving your message as a near perfect example of why developers so often produce code that works on their development machines but not in production.) -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
On Apr 4, 2012, at 5:01 PM, Jan Stary wrote: Using /opt/local as the default prefix is an attempt to save the user from himself, [snip] There are lots of good reasons to use a $prefix other than /usr/local If you care, you can probably find all of the reasoning in the mailing list archives (hint: a long long time ago, /usr/local was the default prefix). It seems to make you mad that you can't use /usr/local ... you actually can if you really want to (I ran that way for a long time), but there's not really a good reason to. I think there's an autoconf check there now that prevents you from doing ./configure --prefix=/usr/local with the source you get (but if you can't figure out how to get around that, you _really_ shouldn't be trying to do it). Don't expect help from others here if you decide to run that way, though. [snip] (*) Yes, the stuff under /usr/local will be used then. That's why the user installed it in there; because that's what he actually intended. You haven't seen the number of times people open tickets saying this port is _broken_ because they have some broken header or library installed in /usr/local This might be overkill, but have you considered adding code to your scripts to mv /usr/local to /usr/localqw (and back at the end)? Or maybe just the lib dir? Thus crippling all my manual installations, such as the backup cronjob script that was about to run, (before the electricity dies out an hour from now)? That was offered as a solution to having stuff in /usr/local that is breaking some port you are trying to build. If you know what you are doing, you can have stuff in /usr/local without too many issues (and you can fix things if/when they break). If you can't figure out how to make things work, then that is a simple workaround. If you don't like it, I'm sure you can hire someone to figure things out for you instead ;-) Perhaps this is the right place to think Jeremy and Ryan and the others for making macports happen in the first place. I hope this comes over as politely as it is intended. I genuinely do think that /usr/local would be a better prefix. it's not. Please point to where I am wrong, and please be very specific and give examples. please see the mailing list archives. -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
On Apr 04 23:32:26, Dominik Reichardt wrote: On 04.04.2012, at 23:20, Jan Stary wrote: On Apr 04 16:05:27, Jeremy Lavergne wrote: /usr/local is not a viable choice because some software (especially auto* tools from Gnu) look in /usr/local as a default location, which means MacPorts can't be easily isolated when needed. I want to kindly ask the person who wrote this to elaborate, and be as specific as can be: what exactly does it mean for macports to be isolated, and how exactly does e.g. auto* looking into /usr/local stand in the way of it? As with the software that magically found its way into /usr/local, how do we stop that very same software from clobbering what MacPorts has installed there? You keep saying that: the software that magically finds its way to /usr/local. What do you even mean by that? The user installed it there; that's about the only way something gets into /usr/local. And how do we stop the user from rewriting something that is already there? We don't, and we can't. It's the user's responsibility to not be an idiot and rewrite something he has installed himself before. In fact, what difference does /usr/local or /opt/local (or any ther prefix for that matter) make in this respect? In the current state of things, how do you stop the user from overwriting something that macports has installed under /opt/local? You don't, because you can't. It's the user's responsibility to not install over something that is already installed (whatever the prefix is). All kinds of software do actually install their stuff in /usr/local on OS X. Examples are a libpng framework from http://ethan.tira-thompson.com/Mac_OS_X_Ports.html (1) Why would anyone use this when libpng is in macports? (2) The site itself says You will have the opportunity to select [the destdir] during installation. or the Sane packages you get through following the links on the official sane site (1) Why would you use this when sane is in macports? (2) http://ljm.home.xs4all.nl/SANE-faq.html#35 SANE sits under /usr/local. (that's the two things that *magically* ended up in my /usr/local). No it didn't magically ended up there. You installed it there. And you were told before you installed it there that it will end up there. I see what you mean, but none of those is an example. The problem is that a couple of packages just install to /usr/local without explicitly stating that or giving the option to use another prefix. This is something you can't avoid and would mess up MacPorts if it were to use /usr/local. That's right. With /opt/local you can't avoid it ether, can you? So in the above example this can mess up MacPorts builds when a port relies on libpng and wants the up to date libpng When a port requires libpng, it says so in its Portfile; and macports will install libpng (as present in macports, not http://ethan.tira-thompson.com/Mac_OS_X_Ports.html) as a dependency. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
On 04.04.2012, at 23:48, Jan Stary wrote: On Apr 04 23:32:26, Dominik Reichardt wrote: On 04.04.2012, at 23:20, Jan Stary wrote: On Apr 04 16:05:27, Jeremy Lavergne wrote: /usr/local is not a viable choice because some software (especially auto* tools from Gnu) look in /usr/local as a default location, which means MacPorts can't be easily isolated when needed. I want to kindly ask the person who wrote this to elaborate, and be as specific as can be: what exactly does it mean for macports to be isolated, and how exactly does e.g. auto* looking into /usr/local stand in the way of it? As with the software that magically found its way into /usr/local, how do we stop that very same software from clobbering what MacPorts has installed there? You keep saying that: the software that magically finds its way to /usr/local. What do you even mean by that? The user installed it there; that's about the only way something gets into /usr/local. And how do we stop the user from rewriting something that is already there? We don't, and we can't. It's the user's responsibility to not be an idiot and rewrite something he has installed himself before. In fact, what difference does /usr/local or /opt/local (or any ther prefix for that matter) make in this respect? In the current state of things, how do you stop the user from overwriting something that macports has installed under /opt/local? You don't, because you can't. It's the user's responsibility to not install over something that is already installed (whatever the prefix is). All kinds of software do actually install their stuff in /usr/local on OS X. Examples are a libpng framework from http://ethan.tira-thompson.com/Mac_OS_X_Ports.html (1) Why would anyone use this when libpng is in macports? Because not everybody is using their mac as you do. I needed the *framework* to provide macports independent snapshots of a game engine and to give people *easy* instructions that do not involve getting macports (2) The site itself says You will have the opportunity to select [the destdir] during installation. that you can select the destination dir seems new to me. Since I'm only using an older package that included ppc arch I no longer keep up to date with this. or the Sane packages you get through following the links on the official sane site (1) Why would you use this when sane is in macports? Independence of macports. (2) http://ljm.home.xs4all.nl/SANE-faq.html#35 SANE sits under /usr/local. (that's the two things that *magically* ended up in my /usr/local). No it didn't magically ended up there. You installed it there. And you were told before you installed it there that it will end up there. I didn't say that, I said *magically*. Of course I know there was no magic involved. Phew... I see what you mean, but none of those is an example. If you see what I mean why are you a ... about it? I'm not trying to get into a wise guy discussion. If *you* want this, let me know so I can let you talk to yourself. The problem is that a couple of packages just install to /usr/local without explicitly stating that or giving the option to use another prefix. This is something you can't avoid and would mess up MacPorts if it were to use /usr/local. That's right. With /opt/local you can't avoid it ether, can you? No, but no software I know about is actually doing it. So in the above example this can mess up MacPorts builds when a port relies on libpng and wants the up to date libpng When a port requires libpng, it says so in its Portfile; and macports will install libpng (as present in macports, not http://ethan.tira-thompson.com/Mac_OS_X_Ports.html) as a dependency. You don't seem to understand. Of course MacPorts WILL install libpng in /opt/local and not http://ethan.tira-thompson.com/Mac_OS_X_Ports.html (I'm wondering what gave yu the impression that I thought MacPorts would do this...) But when the port that requires libpng is then built the compiler may chose the libpng that got installed in /usr/local. I don't know what triggers this, I guess all ports that use autotools and/or libtool might not fall in that trap or I'd have stepped into that pile before. Dom ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
It's the usual Unixy place for third party software, a point you yourself made at some point; how is it you are now unaware of it? Oh I am aware of it, and specifically mention it about two lines below the point where you cut my message, as you know. Nobody uses more then one port system on a given machine Excuse me? Conflicts between the various installer systems happen fairly often, because people *do* try to use multiple installer systems --- as well as third party software independent of them (as above). Do you mean that someone uses, say, both macports and fink? /usr/local is not a viable choice because some software (especially auto* tools from Gnu) look in /usr/local as a default location, which means MacPorts can't be easily isolated when needed. I want to kindly ask the person who wrote this to elaborate, and be as specific as can be: what exactly does it mean for macports to be isolated, and how exactly does e.g. auto* looking into /usr/local stand in the way of it? So, are you at all familiar with the concept of repeatable builds? It is something which has particular importance in the world of packaging systems: it means, among other things, that you can ensure that a package builds the same way and runs the same way on as many systems as possible. MacPorts would not be particularly useful if a port only built properly on its maintainer's machine. Yes, I understand this. What I don't understand is how having /opt/local as a prefix makes this better than having /usr/local (or whatever else). Isolation of the package system is part of what makes this possible. In what way exactly does having /opt/local make this possible as opposed to having /usr/local, which would not make it possible? (I'm not saying it doesn't; it's an honest question.) /usr/local is not a viable choice because it is usually reserved for the given system's admin to install items local to that system, and tends to be a bad choice to have taken over by a non-system port system. Yes, /usr/local i traditionaly used to install items local to that system. How does it make it a bad choice for the macports prefix? The stuff I install from macports IS local to that system! By that same argument, installing anything via apt-get or yum on Linux should install to /usr/local because you're only installing it locally. This is exactly how OpenBSD's pkg_add works, for example: everything goes under /usr/local. I still don't see how that would be wrong here (besides a user himself stupidly rewriting things). You are misunderstanding the point here completely. /usr/local is specifically intended to be left alone by *any* package system. This includes MacPorts. Where did you get this? This is what hier(7) says about /usr/local on my 10.5.8: executables, libraries, etc. not included by the basic operating system How does that exclude stuff from any package system? The definition of /usr/local is a directory where users put things they've compiled themselves; things that did not come from the OS vendor. EXACTLY - such as the macports stuff! That's what I have compiled myself (with the help of a Portfile); that's what did not come from the OS vendor. See? You have lost track of MacPorts being a package system. If you built it yourself, not as part of a package system, that's what /usr/local is for. Me doing './configure ; make ; make install' is a package system. (Not a very good one.) Does that prohibit me from /usr/local? No. Compiling something with macports (or fink or whatever) IS building it myself - except I didn't type the 'make' command with my fingers, it was read from a template. If I manually followed all the steps that macports does when building a package, would I be bulding it myself? As opposed to having it built by macports? No package system should be touching /usr/local. Where did you get this? No really, where does this come from? Again, this is just bad-mouthing. Why would anything under /usr/local (or anything outside of macports) BE a problem, solely on the grounds it is under /usr/local? Really? What rogue software? ...and the fact that you keep repeating this indicates to me that you are not at all experienced in the concept of packaging, or package systems. You know about your own machine, you only care about your own machine; this is fine for you, but you fail to understand that the restrictions MacPorts operates under ensure that it will work on your machine instead of just the port maintainer's machine. That's right: I don't understand how having a default prefix of /opt/local (or /something/deffinitely/other/than/usr/local) ensures that. Ironically, making the changes you claim are the only way that makes sense would probably result in MacPorts being unusable for you. Show me. If the default prefix changed to /usr/local, what exactly would break for me? (No irony here. I
Re: /usr/local question
No it didn't magically ended up there. You installed it there. And you were told before you installed it there that it will end up there. I didn't say that, I said *magically*. Of course I know there was no magic involved. Phew... Jesus, I am not implying you think it was magic. I am just pointing out that you installed it there yourself, and if it broke things, that's not a failure of the packaging system. Of course MacPorts WILL install libpng in /opt/local. But when the port that requires libpng is then built the compiler may chose the libpng that got installed in /usr/local. Yes. And if /usr/local was where macports installs its stuff, then this would mean that the compiler picked up what macports installed, by default. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
On Apr 4, 2012, at 3:39 PM, Jan Stary wrote: No it didn't magically ended up there. You installed it there. And you were told before you installed it there that it will end up there. I didn't say that, I said *magically*. Of course I know there was no magic involved. Phew... Jesus, I am not implying you think it was magic. I am just pointing out that you installed it there yourself, and if it broke things, that's not a failure of the packaging system. Of course MacPorts WILL install libpng in /opt/local. But when the port that requires libpng is then built the compiler may chose the libpng that got installed in /usr/local. Yes. And if /usr/local was where macports installs its stuff, then this would mean that the compiler picked up what macports installed, by default. When MacPorts is prefixed in /opt/local and some process installs files to /usr/local it is easy to move /usr/local out of the way to solve MacPorts installation issues. If MacPorts is prefixed in /usr/local this would be impossible. Regards, Bradley Giesbrecht (pixilla) smime.p7s Description: S/MIME cryptographic signature ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
The user does not know where they installs things. Packaged installers, the users just click through. The user is typically unaware of where packaged software is installed. You can look at our mounds of trouble tickets that were caused by this specific reason. The user simply ran some installer program, and magic happened. And how do we stop the user from rewriting something that is already there? We don't, and we can't. It's the user's responsibility to not be an idiot and rewrite something he has installed himself before. That is a reason why we shouldn't use /usr/local: users are less to ran an installer that clobbers inside MacPorts-specific directories. There is a huge difference between: * the user explicitly running a command to overwrite MacPorts, and * the user ran an installer that did something somewhere. When the user runs an installer program, chances are it won't install to /opt/local but instead install to /usr/local or /Library. Since /usr/local is a prime target, it would be very likely that users routinely overwrite MacPorts on accident. OK. This convinces me that /usr/local would not be good. Thank you for your time. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
Hi, On Apr 04 11:26:14, Jeremy Lavergne wrote: /usr/local is horrible because it takes precedence over everything else on your system Yes, it takes precedence. That's the point: to have a place where things are supposed to be installed. Why does it make /usr/local horrible? How would that be less horrible if it was any other directory? This means incorrect libraries and headers that magically find their way in there via other installers will be used instead of the software that was actually intended. Whoa, stop right there. This paragraph makes no argument against /usr/local, it's just dissing it with meanlessly negative adjectives. (*) What incorrect libraries and headers? The headers and libraries I install under /usr/local (or anywhere else, for that matter) manually (or any other way, for that matter) are no more or less correct than those installed by macports (or any other installer, for that matter). (*) How exactly do they magically find their way into /usr/local? The user installs it there! (*) Yes, the stuff under /usr/local will be used then. That's why the user installed it in there; because that's what he actually intended. I think you are missing an important point. MacPorts has a hard enough time making sure its own internal ecosystem is consistent and works with itself. Making sure all the various versions of the packages MacPorts has available are consistent and compatible with themselves is a massive job. Just because you have installed something in /usr/local, and think it is the version you want used, does *not* mean that version is compatible with what MacPorts needs, up to date, or plain working at all. Macports tends to keep itself up to date, more or less, but it has absolutely no way to know whether *you* are doing the same for what you put in /usr/local More over, there are some packages MacPorts provides that conflict with each other. You *cannot* have both installed at once. MacPorts provides both, so the user can decide. Given all of this, it is I think unreasonable to expect MacPorts to be compatible with whatever it happens to find in /usr/local. It *has* to have complete control over what it uses, in order to be able to have some chance of making sure things work OK. Given the way, as others have described, /usr/local finds its way into various compilers and utilities, whether you want it to or not, the only approach I can see MacPorts taking is leaving it up to the user. If a problem occurs, and that problem is due to /usr/local, it is I think completely reasonable for the response to be try again without whatever you have in /usr/local. cheers Chris smime.p7s Description: S/MIME cryptographic signature ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
Hi, Yes, I understand this. What I don't understand is how having /opt/local as a prefix makes this better than having /usr/local (or whatever else). Its just statistics. /usr/local is a relatively common place for third party applications to dump stuff, so usin git you are likely to conflict, sooner or later. /opt/local is much less likely, whilst still being not being a totally wacky location... MacPorts does provide a means to set its installation root, so if *you* really want to use /usr/local you can. Similarly you could use /opt/I/bet/no/one/will/ever/find/this/ to be completely safe … MacPorts devs only fully support /opt/local, as that is what they recommend and the vast majority of people use, so is most tested. Chris smime.p7s Description: S/MIME cryptographic signature ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
This ksh command line:
for y in ${PATH//:/ } ; do for x in $y/* ; do if [[ -r $x ]] ; then strings
$x | grep -sq /usr/local print `basename $x` ; fi ; done ; done | sort -u
| wc -l
produces 123 hits on my system. The same command, but using /opt/local,
produces 834. Only 28 commands are in both lists.
Greg Shenaut
smime.p7s
Description: S/MIME cryptographic signature
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
On Wed, Apr 4, 2012 at 18:19, Jan Stary h...@stare.cz wrote: It's the usual Unixy place for third party software, a point you yourself made at some point; how is it you are now unaware of it? Oh I am aware of it, and specifically mention it about two lines below the point where you cut my message, as you know. Yes, so why are you so confused about it? Nobody uses more then one port system on a given machine Excuse me? Conflicts between the various installer systems happen fairly often, because people *do* try to use multiple installer systems --- as well as third party software independent of them (as above). Do you mean that someone uses, say, both macports and fink? Or macports and homebrew, or fink and homebrew, absolutely yes. It's a bad idea but it's a common one (and one which homebrew tries to encourage, often with very unfortunate results, although I gather they're learning the hard way the lesson you seem to be going out of your way to not figure out). /usr/local is not a viable choice because some software (especially auto* tools from Gnu) look in /usr/local as a default location, which means MacPorts can't be easily isolated when needed. I want to kindly ask the person who wrote this to elaborate, and be as specific as can be: what exactly does it mean for macports to be isolated, and how exactly does e.g. auto* looking into /usr/local stand in the way of it? So, are you at all familiar with the concept of repeatable builds? It is something which has particular importance in the world of packaging systems: it means, among other things, that you can ensure that a package builds the same way and runs the same way on as many systems as possible. MacPorts would not be particularly useful if a port only built properly on its maintainer's machine. Yes, I understand this. What I don't understand is how having /opt/local as a prefix makes this better than having /usr/local (or whatever else). That is extremely evident. If I keep MacPorts in its own prefix, it is easier to ensure that other software on my system does not get mixed up in a build. As a port maintainer, this means I can produce a port that does not accidentally depend on software that MacPorts doesn't know about, which would lead to other people who try to install my port getting unexpected errors because they don't have that software installed, or (much harder to diagnose) have the wrong version of it installed. Isolation of the package system is part of what makes this possible. In what way exactly does having /opt/local make this possible as opposed to having /usr/local, which would not make it possible? Because, as you repeatedly point out, *other* software (not related to MacPorts) is also installed in that location. If it's all intermingled, I can't reliably keep it from being found and used when building software for MacPorts. If MacPorts is in its own tree, I can at absolute worst move other trees to archival storage (but usually just rename them to something that won't be searched automatically the way /usr/local is) and now I can do a build which I *know* doesn't depend on some other software I'd forgotten about. This is important if I intend that build (or in the case of MacPorts, the Portfile that does the build) to be usable by other people on random other machines. This is what repeatable build is about. /usr/local is not a viable choice because it is usually reserved for the given system's admin to install items local to that system, and tends to be a bad choice to have taken over by a non-system port system. Yes, /usr/local i traditionaly used to install items local to that system. How does it make it a bad choice for the macports prefix? The stuff I install from macports IS local to that system! By that same argument, installing anything via apt-get or yum on Linux should install to /usr/local because you're only installing it locally. This is exactly how OpenBSD's pkg_add works, for example: I know; FreeBSD ports does the same thing. And it causes problems quite often when third party packages are also installed under /usr/local. MacPorts changed to /opt/local in part *because* of that experience; I suspect the BSDs would change as well if it wouldn't cause significant pain to users. You are misunderstanding the point here completely. /usr/local is specifically intended to be left alone by *any* package system. This includes MacPorts. Where did you get this? This is what hier(7) says about /usr/local on my 10.5.8: executables, libraries, etc. not included by the basic operating system How does that exclude stuff from any package system? This is based on the BSD model, which as I just described above is actually fairly broken. See for comparison what Linux's FHS has to say about it (FHS also learned from BSD's mistake). When I described repeatable
Re: /usr/local question
On Wed, Apr 4, 2012 at 19:08, Chris Jones jon...@hep.phy.cam.ac.uk wrote: MacPorts does provide a means to set its installation root, so if *you* really want to use /usr/local you can. Similarly you could use /opt/I/bet/no/one/will/ever/find/this/ to be completely safe … Actually, I think it specifically refuses /usr/local (you'd have to edit the script to enable that particular flavor of foot-shooting). -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
Hello, There is a problem with having many locations for third party installed software and that is dependencies during build and paths to those dependencies. Sometimes the problem also crops up when applications are opened depending on how the library links are sought (this is very very rare; but, does occur). If the build path is hard specified for dependencies, then, there is no problem because the dependency search will find or not find the dependency at the proper location; otherwise, PATH is used and the order of search of PATH will determine in which location a particular dependency is found to be used, a problem if there is more than one version of a dependency active at a time for the different installed port. I have actually had this happen a couple of times when trying to install non-MacPorts third party software into usr/local and having the dependency found in opt/local. On Apr 4, 2012, at 11:44 AM, Phil Dobbin wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/04/2012 19:40, Phil Dobbin wrote: On 04/04/2012 18:30, Saiwing Yeung wrote: On Apr 4, 2012, at 9:19 AM, Ryan Schmidt wrote: On Apr 4, 2012, at 11:16, Saiwing Yeung wrote: oh... I didn't know that. I just took a look in my /usr/local, and found a whole bunch of stuff for texlive, and then various programs that I remember installing. is there a recommended place for me to put these programs? Any other place on the hard drive that doesn't already have a defined meaning. So any prefix other than /, /usr, /usr/local, /opt/local or /sw should be fine. Thanks! In addition, I agree with Jan Stary that it would be nice to amend the #defaultprefix: section in the FAQ. If possible, it would also be nice to also add this to the A port fails to build. What should I do? section in the FAQ, as the section title of #defaultprefix is Why is /opt/local the default install location for MacPorts? and if a port fails to build for me, I probably wouldn't realize that pertinent information is in that section. If you want to install in directories other than /usr/local to avoid any conflicts with Mac Ports, you could use the other *nix location $HOME/bin. On most, if not all, Linux distros that PATH is already present in ~/.bashrc. You'd probably have to create the directory in /Users/yourname as well as add the above line to your bash_profile but I use $HOME/bin a lot on OS X Linux. It also has the added advantage of not having to use sudo when installing stuff. the above (non-existent) line of course being: `PATH=$PATH:$HOME/bin` :-) - -- But masters, remember that I am an ass. Though it be not written down, yet forget not that I am an ass. Wm. Shakespeare - Much Ado About Nothing -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: §auto-key-locate cert pka ldap hkp://keys.gnupg.net Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPfJaEAAoJEKpMeDHWT5ADxUcIAJXB53+Kh0Pqweu2TJcwdJYS Yko/t3Bg2cnfT7QZQ0+ZzVulmU5UUsQ7TkgU4b4alVzTDwzyePsU/bGe+DTGLAjZ jH40FgQz8Bf1odJE7akSzPc3QGpF+BfpU0OOVC+nZ5JKb10nt+GG8KDU3EEZVhEH KH0Pq6u03VeKv1cLFaUQa3Do8cjas9tbRcZEMirykKV7i5r5Vu8uj6bqraA/yHyD dWKoE7yHROLRtkwfdur6kiqA2+V2UZCkwGcuxCOnGPJ6ERc1dSrhlr2AKTGmx9LZ u6NBSYN1FDjVTwCjBASfplzc4F0f2ZASPJMcVbyOEe0Rdb7aAZvoYGPloDwki8U= =Jh6Q -END PGP SIGNATURE- ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users Frank J. R. Hanstick tro...@comcast.net ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
