Re: /usr/local question
Am 05.04.2012 um 00:39 schrieb Jan Stary h...@stare.cz: 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. You were behaving like a pedantic wise guy, bordering on trolling, so why not have fun with you. 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, Yes, we know that, we wrote so a couple of times. The problem arises from all other stuff that gets installed there and would silently overwrite stuff. Or from stuff that got installed there before MacPort was even installed. Most people don't keep track of what they installed over time. That's why they use a package manager like MacPorts ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
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. No, not really. You have macports stuff in its own prefix, namely, /opt/local. However, if a given port silently picks up something incompatible in /usr/local, if might fail and often will. Having macports isolated in /opt/local DID NOT save you from this. Removing /usr/local is what did. This is the distinction I am trying to make, and that's what I find confusing about the FAQ entry as it stands now. Do you see my point now? I agree now that /usr/local is on fact a bad choice. What I find cnfusing or unclear is the reasoning about it in the the FAQ. The most prominent reason given to me yesterday for not having /usr/local as a default prefix was that people will stupidly rewrite the stuff in there by blindly clicking through third-party installers. That for example is not mentioned in the FAQ at all. As a port maintainer, this means I can produce a port that does not accidentally depend on software that MacPorts doesn't know about, Again, this is not entirely true: the proper way for a port to not accidently pick up unwanted dependencies is to say --disable-whatever in the Portfile (and yes, I have run into that problem in ports I maintain). Not all ports provide a way to declare this, so you make sure it doesn't happen by removing /usr/local altgether, or making the user remove his /usr/local, which you will agree is a pretty extreme measure on a UNIX system. That's not repeatable build, that's alibism; in fact, it is exactly what you were (rightfully) arguing against before: such a build is only repeatable on systems that do look like the maintainer's system, namely, they do not have anything in /usr/local. In other words, the thing that makes your build repeatable is that there is nothing around that the port might accidentally pick up, not that macports is under /opt/local. Obviously, to be able to do this, you must have macports somewhere else than /usr/local, because /usr/local might be at certain ports REQUIRED NOT TO EXIST. This explicit reason is what I am missing in the FAQ. 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. But the problem is not that the incompatible third party software is installed IN THAT LOCATION; the problem is that incompatbile software is found and picked up AT ALL. Having macports in /opt/local does not solve this; not having the other software around is what does. If it's all intermingled, I can't reliably keep it from being found and used when building software for MacPorts. An if it's NOT intermingled (specifically, macports stuff under /opt/local, other stuff under /usr/local) IT WILL STILL be found and used. Do you see my point now? 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) Yes, that will solve it. But only this, what you call absolute worst, is actually the point that makes the build repeatable, isn't it. 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. Yes - as long as they also do not have /usr/local on their system, which they most probably do. This is what repeatable build is about. No. It would be repeatable if it built as fine on a system that has shit under /usr/local as it does on your system that does not. That would be repeatable. Requiring the user to make his system look (temporarily) like yours is not what you could call repeatable. 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). I have been using this mistaken, broken system for years without problems, thank you. No package system should be touching /usr/local. Where did you get this? No really, where does this come from? Years of experience by most people who have to manage anything larger than their one home system, Such as FreeBSD or OpenBSD? I really don't mean this to be offensive in any way. I am glad I have macports, and it helps me very much. I just think that the explanation about /opt/local and /usr/local in the FAQ is not very clear. I will try to come up with a better reformulation based on what people have explained to me here. At any rate, thank you for your time. Jan
Re: /usr/local question
On 5 Apr 2012, at 2:20am, Brandon Allbery wrote: 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). Didn't know that one, thanks. Sounds sensible… 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
I agree now that /usr/local is on fact a bad choice. What I find cnfusing or unclear is the reasoning about it in the the FAQ. The most prominent reason given to me yesterday for not having /usr/local as a default prefix was that people will stupidly rewrite the stuff in there by blindly clicking through third-party installers. That for example is not mentioned in the FAQ at all. I will try to come up with a better reformulation based on what people have explained to me here. OK, here is what I propose as a relacement/extension of FAQ#defaultprefix. Does this correctly describe the reasoning that was kindly explained to me in the previous discussion? Obviously, I would like this OK'd here before I mangle the wiki. (The XXX is where my English fails me. Could a native speaker put the right verb in please that seems to slip my mind?) * Why is /opt/local the default install location for MacPorts? Traditionally, the place to install third party software on many UNIX systems is /usr/local. However, having macports under /usr/local would be error-prone. Many other software packages and packaging systems install in there, and would accidentaly overwrite what macports has installed, or vice versa. While this could be XXXed off as the user's own error, it is a fact that users click through installers blindly, and consequently collisions under /usr/local (and other prominent directories) happen very often. Macports doesn't want to be a victim of that, and /opt/local provides the splendid isolation - as would any other dedicated directory, of course. Also, /usr/local is traditionally reserved for the given system's admin to install local tools; macports doesn't want to stomp on that either. (For the same reasons, fink uses /sw as its prefix.) * So with macports under /opt/local I can use /usr/local freely? No, not entirely. Even with macports living elsewhere, /usr/local can still interfere. Some software (especially the GNU auto* tools and gcc) looks into /usr/local for external headers, libraries, and binaries. Ceratin ports might (and do) fail to build because during their build something incompatible is found and picked up from /usr/local. Good ports avoid this by explicitly specifying --with-libfoo=/opt/local/lib/ or explicitly disabling all such possible dependencies altogehter with --disable-foo or --without-bar, but not all ports are able to do that. In some cases, it might even be necessary to temporarily make /usr/local disappear entirely for a given port to build successfully. Obviously this wouldn't be possible if macports itself lived under /usr/local. (And a third which I don't expect to be let through: * So in order to build a given broken port with macports, you advice me to remove /usr/local altogether, thus crippling my system for the duration of the build? Sadly, yes.) ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
On Apr 05 09:00:44, Jan Stary wrote: However, if a given port silently picks up something incompatible in /usr/local, if might fail and often will. Having macports isolated in /opt/local DID NOT save you from this. Removing /usr/local is what did. One more point to this: what if the colliding, incompatible software that stops a given port from building successfully is not found under /usr/local, but in /usr, which is even more prominently recognized by various build tools. That's not made up: /usr/lib/libssl.* Say the port requires a newer version of openssl than what /usr/lib/libssl.* provides. That's the same situation as with a port not building because some incompatbile software was found and picked up from /usr/local; except now it is /usr. What is the advice here? Ceratinly not to temporarily rename /usr. I argue that temporarily removing /usr/local is just as bad, and the problem of a port picking bad stuff from /usr/local is that given port's defect that needs to be fixed before the port gets built; not a reason to remove /usr/local. (Which doesn't change the fact that /opt/local is a better prefix, I am over that already.) ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
As far as I can tell, /usr in PATH is being honored opposed to /usr/local being picked up automatically. Am 05.04.2012 um 10:25 schrieb Jan Stary h...@stare.cz: On Apr 05 09:00:44, Jan Stary wrote: However, if a given port silently picks up something incompatible in /usr/local, if might fail and often will. Having macports isolated in /opt/local DID NOT save you from this. Removing /usr/local is what did. One more point to this: what if the colliding, incompatible software that stops a given port from building successfully is not found under /usr/local, but in /usr, which is even more prominently recognized by various build tools. That's not made up: /usr/lib/libssl.* Say the port requires a newer version of openssl than what /usr/lib/libssl.* provides. That's the same situation as with a port not building because some incompatbile software was found and picked up from /usr/local; except now it is /usr. What is the advice here? Ceratinly not to temporarily rename /usr. I argue that temporarily removing /usr/local is just as bad, and the problem of a port picking bad stuff from /usr/local is that given port's defect that needs to be fixed before the port gets built; not a reason to remove /usr/local. (Which doesn't change the fact that /opt/local is a better prefix, I am over that already.) ___ 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 Apr 05 10:49:01, Dominik Reichardt wrote: As far as I can tell, /usr in PATH is being honored opposed to /usr/local being picked up automatically. I don't know how honored differs from being picked up, but PATH has nothing to do with this. Am 05.04.2012 um 10:25 schrieb Jan Stary h...@stare.cz: On Apr 05 09:00:44, Jan Stary wrote: However, if a given port silently picks up something incompatible in /usr/local, if might fail and often will. Having macports isolated in /opt/local DID NOT save you from this. Removing /usr/local is what did. One more point to this: what if the colliding, incompatible software that stops a given port from building successfully is not found under /usr/local, but in /usr, which is even more prominently recognized by various build tools. That's not made up: /usr/lib/libssl.* Say the port requires a newer version of openssl than what /usr/lib/libssl.* provides. That's the same situation as with a port not building because some incompatbile software was found and picked up from /usr/local; except now it is /usr. What is the advice here? Ceratinly not to temporarily rename /usr. I argue that temporarily removing /usr/local is just as bad, and the problem of a port picking bad stuff from /usr/local is that given port's defect that needs to be fixed before the port gets built; not a reason to remove /usr/local. (Which doesn't change the fact that /opt/local is a better prefix, I am over that already.) ___ 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
Honoring the order in PATH so when /opt/local is in front of /usr, compilers will honor that. So yes PATH has a lot to do with this. Opposed to the /usr/local issue. Check your attitude please Am 05.04.2012 um 10:59 schrieb Jan Stary h...@stare.cz: On Apr 05 10:49:01, Dominik Reichardt wrote: As far as I can tell, /usr in PATH is being honored opposed to /usr/local being picked up automatically. I don't know how honored differs from being picked up, but PATH has nothing to do with this. Am 05.04.2012 um 10:25 schrieb Jan Stary h...@stare.cz: On Apr 05 09:00:44, Jan Stary wrote: However, if a given port silently picks up something incompatible in /usr/local, if might fail and often will. Having macports isolated in /opt/local DID NOT save you from this. Removing /usr/local is what did. One more point to this: what if the colliding, incompatible software that stops a given port from building successfully is not found under /usr/local, but in /usr, which is even more prominently recognized by various build tools. That's not made up: /usr/lib/libssl.* Say the port requires a newer version of openssl than what /usr/lib/libssl.* provides. That's the same situation as with a port not building because some incompatbile software was found and picked up from /usr/local; except now it is /usr. What is the advice here? Ceratinly not to temporarily rename /usr. I argue that temporarily removing /usr/local is just as bad, and the problem of a port picking bad stuff from /usr/local is that given port's defect that needs to be fixed before the port gets built; not a reason to remove /usr/local. (Which doesn't change the fact that /opt/local is a better prefix, I am over that already.) ___ 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 ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
The thread has pointed out that there would not be an issue if that were the case: it appears Gnu toolchain puts /usr/local first. Dominik Reichardt domi...@gmail.com wrote: Honoring the order in PATH so when /opt/local is in front of /usr, compilers will honor that. So yes PATH has a lot to do with this. Opposed to the /usr/local issue. Check your attitude please Am 05.04.2012 um 10:59 schrieb Jan Stary h...@stare.cz: On Apr 05 10:49:01, Dominik Reichardt wrote: As far as I can tell, /usr in PATH is being honored opposed to /usr/local being picked up automatically. I don't know how honored differs from being picked up, but PATH has nothing to do with this. Am 05.04.2012 um 10:25 schrieb Jan Stary h...@stare.cz: On Apr 05 09:00:44, Jan Stary wrote: However, if a given port silently picks up something incompatible in /usr/local, if might fail and often will. Having macports isolated in /opt/local DID NOT save you from this. Removing /usr/local is what did. One more point to this: what if the colliding, incompatible software that stops a given port from building successfully is not found under /usr/local, but in /usr, which is even more prominently recognized by various build tools. That's not made up: /usr/lib/libssl.* Say the port requires a newer version of openssl than what /usr/lib/libssl.* provides. That's the same situation as with a port not building because some incompatbile software was found and picked up from /usr/local; except now it is /usr. What is the advice here? Ceratinly not to temporarily rename /usr. I argue that temporarily removing /usr/local is just as bad, and the problem of a port picking bad stuff from /usr/local is that given port's defect that needs to be fixed before the port gets built; not a reason to remove /usr/local. (Which doesn't change the fact that /opt/local is a better prefix, I am over that already.) ___ 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 ___ 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 Apr 05 11:06:51, Dominik Reichardt wrote: Honoring the order in PATH so when /opt/local is in front of /usr, compilers will honor that. PATH is where the binaries are looked for. I am talking about libraries; compilers do not look for libraries in PATH. So yes PATH has a lot to do with this. Opposed to the /usr/local issue. Check your attitude please Check what PATH 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 05 04:13:44, Jeremy Lavergne wrote: The thread has pointed out that there would not be an issue if that were the case: it appears Gnu toolchain puts /usr/local first. Even if the build tools put /usr/local before /usr, the example still stands: I don't have /usr/local at all. I have an old, incompatible version of openssl in /usr/lib/libssl.*, and a port that fails to build because it picks that up. What happens then? Should I temporarily rename /usr so that the port does not pick that up and builds successfully? Am 05.04.2012 um 10:25 schrieb Jan Stary h...@stare.cz: On Apr 05 09:00:44, Jan Stary wrote: However, if a given port silently picks up something incompatible in /usr/local, if might fail and often will. Having macports isolated in /opt/local DID NOT save you from this. Removing /usr/local is what did. One more point to this: what if the colliding, incompatible software that stops a given port from building successfully is not found under /usr/local, but in /usr, which is even more prominently recognized by various build tools. That's not made up: /usr/lib/libssl.* Say the port requires a newer version of openssl than what /usr/lib/libssl.* provides. That's the same situation as with a port not building because some incompatbile software was found and picked up from /usr/local; except now it is /usr. What is the advice here? Ceratinly not to temporarily rename /usr. I argue that temporarily removing /usr/local is just as bad, and the problem of a port picking bad stuff from /usr/local is that given port's defect that needs to be fixed before the port gets built; not a reason to remove /usr/local. (Which doesn't change the fact that /opt/local is a better prefix, I am over that already.) ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
So /usr/local is kept hostage by crap GNU tools. I do note that most Linux distros manage to convince even GNU crapware to install somewhere outside /usr/local. I'd be surprised if they permitted their builds to get distracted by stuff in /usr/local. But then they tend (Gentoo excepted) to provide prebuilt packages, rather than expecting you to build from source. Maybe their solution is purely to build on systems with empty /usr/local. I'm guessing that some of the errant GNUware could be fixed by source patches which upstream might refuse to apply. Do we have such patches available? I'm guessing that the rest probably require source fixes and recompiling everything else GNU that's broken, including compilers, binutils, etc. These build-essential ports should perhaps be made available as compiled packages, rather than expecting people to bootstrap their own from source. I'll mention that NetBSD has used /usr/pkg for ages, rather than /usr/local, and is having a bunfight/bikeshed about the few remaining packages that insist on trashing the file system before a package can be made. Most of their package builds now do a staging install outside the final resting place before making a package, and that you then use the package to install from. Maybe they have patches available to prevent poisoning from /usr/local? I believe they use their prerequisite feature to ensure that the required ports are already installed in /usr/pkg, and tweak ./configure arguments to know the directories they are in. I'll also mention that OpenBSD exclusively uses packages which are compiled elsewhere; all ported software is installed from packages; they have already reached where NetBSD is trying to get to. In addition, OpenBSD culture is to install from packages, not by building from source yourself. Maybe they have patches which prevent GNU crapware from inspecting bogus locations before building packages? OpenBSD also uses prerequisite packages and configure tweaks to ensure that the stuff they use is installed in /usr/local from OpenBSD packages, and to use the required directories installed from those packages. Macports is the only software packaging system I follow which seems to suffer from /usr/local issues. This is a pity, since I use it on my main development system, and I can't afford the Apple tax to buy a separate Apple machine (without /usr/local) just to build ports on. I can't believe that this problem hasn't already been solved on some of the OSs and packaging systems I've mentioned. But in the end, I will support those who do development on Macports by acknowledging that they don't have excess capacity. We'd rather they be porting or updating the stuff we actually want to use, rather than spend their effort fixing all the GNU crap used to build them. -- Christopher On 05-Apr-2012, at 18:12 , Jan Stary wrote: I agree now that /usr/local is on fact a bad choice. What I find cnfusing or unclear is the reasoning about it in the the FAQ. The most prominent reason given to me yesterday for not having /usr/local as a default prefix was that people will stupidly rewrite the stuff in there by blindly clicking through third-party installers. That for example is not mentioned in the FAQ at all. I will try to come up with a better reformulation based on what people have explained to me here. OK, here is what I propose as a relacement/extension of FAQ#defaultprefix. Does this correctly describe the reasoning that was kindly explained to me in the previous discussion? Obviously, I would like this OK'd here before I mangle the wiki. (The XXX is where my English fails me. Could a native speaker put the right verb in please that seems to slip my mind?) * Why is /opt/local the default install location for MacPorts? Traditionally, the place to install third party software on many UNIX systems is /usr/local. However, having macports under /usr/local would be error-prone. Many other software packages and packaging systems install in there, and would accidentaly overwrite what macports has installed, or vice versa. While this could be XXXed off as the user's own error, it is a fact that users click through installers blindly, and consequently collisions under /usr/local (and other prominent directories) happen very often. Macports doesn't want to be a victim of that, and /opt/local provides the splendid isolation - as would any other dedicated directory, of course. Also, /usr/local is traditionally reserved for the given system's admin to install local tools; macports doesn't want to stomp on that either. (For the same reasons, fink uses /sw as its prefix.) * So with macports under /opt/local I can use /usr/local freely? No, not entirely. Even with macports living elsewhere, /usr/local can still interfere. Some software (especially the GNU auto* tools and gcc) looks into /usr/local for external headers, libraries, and binaries. Ceratin
Re: /usr/local question
On Apr 05 19:52:23, Christopher Vance wrote: I'll also mention that OpenBSD exclusively uses packages which are compiled elsewhere; all ported software is installed from packages; they have already reached where NetBSD is trying to get to. In addition, OpenBSD culture is to install from packages, not by building from source yourself. Yes. I come from OpenBSD and miss this in macports. Maybe they have patches which prevent GNU crapware from inspecting bogus locations before building packages? No. They simply have CONFIGURE_ARGS in the Makefiles (analogously, macports has configure.args in Portfiles) and it is each port's bussines to set that appropriatelly. And when a port fails to do that properly, and picks up something unsuitable that the packaging system doesn't know about (which does happen), it is considered that port's problem. OpenBSD also uses prerequisite packages and configure tweaks to ensure that the stuff they use is installed in /usr/local from OpenBSD packages, That's not done by configure tweaks - checksums are kept for the installed files. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
On 2012-04-05, Jan Stary h...@stare.cz wrote: (The XXX is where my English fails me. Could a native speaker put the right verb in please that seems to slip my mind?) [...] While this could be XXXed off as the user's own error, it is a fact that written off as chalked up to dismissed as -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
On Apr 05 08:47:47, Arno Hautala wrote: On 2012-04-05, Jan Stary h...@stare.cz wrote: (The XXX is where my English fails me. Could a native speaker put the right verb in please that seems to slip my mind?) [...] While this could be XXXed off as the user's own error, it is a fact that written off as chalked up to dismissed as ah, dismissed, thanks. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
On Apr 5, 2012, at 12:00 AM, Jan Stary wrote: Again, this is not entirely true: the proper way for a port to not accidently pick up unwanted dependencies is to say --disable-whatever in the Portfile (and yes, I have run into that problem in ports I maintain). Not all ports provide a way to declare this, so you make sure it doesn't happen by removing /usr/local altgether, or making the user remove his /usr/local, which you will agree is a pretty extreme measure on a UNIX system. Simply put, MacPorts does not SUPPORT /usr/local in the sense that if you ask for help from MacPorts we are going to ask you to move /usr/local out of the way rather then tediously work though the contents of /usr/local. Our resources are better spent on other tasks. 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
On Apr 05 08:25:49, Bradley Giesbrecht wrote: On Apr 5, 2012, at 12:00 AM, Jan Stary wrote: Again, this is not entirely true: the proper way for a port to not accidently pick up unwanted dependencies is to say --disable-whatever in the Portfile (and yes, I have run into that problem in ports I maintain). Not all ports provide a way to declare this, so you make sure it doesn't happen by removing /usr/local altgether, or making the user remove his /usr/local, which you will agree is a pretty extreme measure on a UNIX system. Simply put, MacPorts does not SUPPORT /usr/local in the sense that if you ask for help from MacPorts we are going to ask you to move /usr/local out of the way rather then tediously work though the contents of /usr/local. Our resources are better spent on other tasks. I respect that. However, I believe that if a port chokes on picking up some unintended dependency it found in /usr/local (or anywhere, for that matter), it is that port's problem: I don't think it's /usr/local's fault being there - I think it's the port's defect geting confused by that. Hence in terms of the (limited) resources, I believe it's the port maintainer's job to rectify this by actually fixing that (broken) port so that it no longer gets confused. I am willing to help this with ports that interest me. Is there a way in trac to specifically select the ports that have this problem? (Or is there even a keyword for that, such as 'usrlocal', 'externalconflict' or whatever?) 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 5, 2012, at 11:44 AM, Jan Stary wrote: However, I believe that if a port chokes on picking up some unintended dependency it found in /usr/local (or anywhere, for that matter), it is that port's problem: I don't think it's /usr/local's fault being there - I think it's the port's defect geting confused by that. You are wrong. We try to make things work (even if stuff is in /usr/local) but because cc/ld/cpp/dyld/etc. search /usr/local by default, it can cause problems. You can look through the mailing list archives for examples. Hence in terms of the (limited) resources, I believe it's the port maintainer's job to rectify this by actually fixing that (broken) port so that it no longer gets confused. we do when we can. I am willing to help this with ports that interest me. Is there a way in trac to specifically select the ports that have this problem? not that I know of (since you don't know what is going to be in /usr/local on any machine) the /real/ fix would be to either: - change build behavior for cc/ld/cpp (which may be possible, but no one has tried to do it as far as I know) -nostdinc (or equivalent) plus adding back the appropriate search paths for every supported platform - change build behavior for cc/ld/cpp by getting a macports version of the toolchain working (and patched to not pull in /usr/local by default) - get trace mode working so that it can be used at all times (and can prevent things from being found in /usr/local) [this is probably the best solution] -- 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: How to run a sql script sql script on mysql5
On Wed, 4 Apr 2012, 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 ? Close, but try this: sudo mysql5 -u root -p password script.sql -- Michael Parson Unix Thug Austin, TX KF5LGQ ___ 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 5, 2012, at 9:21 AM, Michael Parson wrote: On Wed, 4 Apr 2012, 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. 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 ? Close, but try this: sudo mysql5 -u root -p password script.sql If script.sql does not create/use a database you may need to add the database to the command. $ mysql5 -uroot -p -e create database if not exists dbname; $ mysql5 -uroot -p dbname script.sql 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
On 06/04/2012, at 1:56 AM, Daniel J. Luke wrote:
On Apr 5, 2012, at 11:44 AM, Jan Stary wrote:
I am willing to help this with ports that interest me.
Is there a way in trac to specifically select the ports
that have this problem?
not that I know of (since you don't know what is going to be in /usr/local on
any machine)
the /real/ fix would be to either:
- change build behavior for cc/ld/cpp (which may be possible, but no one has
tried to do it as far as I know) -nostdinc (or equivalent) plus adding back
the appropriate search paths for every supported platform
- change build behavior for cc/ld/cpp by getting a macports version of the
toolchain working (and patched to not pull in /usr/local by default)
- get trace mode working so that it can be used at all times (and can prevent
things from being found in /usr/local) [this is probably the best solution]
There has been much mention of $PATH in this discussion (the classic way to
determine
the order of priority in which executables are picked up in a Unix-like
system), but I have seen
no mention of other environment variables, nor do I see that they have been set
('env | sort' )
after I have installed Macports and a few ports.
Some variables I rely on when developing programs, so that I link to the
correct (development)
libraries etc. are $LD_LIBRARY_PATH and $PKG_CONFIG_PATH, but there are also
$QT_PLUGIN_PATH (when using a Qt library), $PYTHON_SITE_PACKAGES and (using
CMake) $CMAKE_PREFIX_PATH, $CMAKE_LIBRARY_PATH and $CMAKE_INCLUDE_PATH.
I am not sure what all these do and to what extent they are local to KDE or Qt,
but in my setup
script, for development and testing, the last three get prepended with
/opt/local, /opt/local/lib
and /opt/local/include and then prepended again with locations for development
versions of
KDE executables, libraries and includes, so I always get the executables,
libraries and includes
I need for KDE development and testing.
I wonder if Macports could make more use of similar variables to avoid picking
up unwanted
includes or libraries from /usr/local. Maybe it does. In which case, I do not
see how it could fall
foul of /usr/local, so please excuse me for rabitting on.
Cheers, Ian W.
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: /usr/local question
On 05/04/2012, at 10:00 PM, macports-users-requ...@lists.macosforge.org 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? 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. This is not smoke-and-mirrors. I cannot see anything that would affect, and none of my macports are affected by the tex stuff in /usr/local If you are not a 'developer' and the concept of 'include files' libararies' 'executables' is alien sure adopt the 'never use /usr/local' paradigsm else just be sensible James ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
