OK, here is what I propose as a relacement/extension of FAQ#defaultprefix.
* Why is /opt/local the default install location for MacPorts?
* So with macports under /opt/local I can use /usr/local freely?
I just commited this (fixing the typos.)
https://trac.macports.org/wiki/FAQ#defaultprefix
On Apr 10, 2012, at 8:00 AM, Jan Stary wrote:
OK, here is what I propose as a relacement/extension of FAQ#defaultprefix.
* Why is /opt/local the default install location for MacPorts?
* So with macports under /opt/local I can use /usr/local freely?
I just commited this (fixing the typos.)
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)
I tried searching in both the mailing list archives and trac;
On Apr 10, 2012, at 11:21 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)
I tried
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...
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
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
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
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
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
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
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:
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
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
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
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
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
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
--
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
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
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
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
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
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
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
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.
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
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
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
-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?
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
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
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
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
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
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
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:
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
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
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
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?
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
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
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
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
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:
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
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
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
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!
-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,
-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
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
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
/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
-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
`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
-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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
a lot of mdutil activities. What do people do to automate
this, or to make the process easier? Thanks!
--
View this message in context:
http://old.nabble.com/-usr-local-question-tp33545041p33545041.html
Sent from the MacPorts - Users mailing list archive at Nabble.com
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/04/2012 01: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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/04/2012 01:57, Jeremy Lavergne 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.
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
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.
82 matches
Mail list logo
