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 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 a
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 t
> 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#defaultprefi
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 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 goin
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 de
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 proble
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:47:47, Arno Hautala wrote:
> On 2012-04-05, Jan Stary 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 th
On 2012-04-05, Jan Stary 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 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 pac
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 prov
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
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 t
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 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.
>Opp
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 :
> On Apr 05 10:49:01, Dominik Reichardt wrote:
>> As far as
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 :
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 :
> 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 ofte
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 col
> 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 bli
On 5 Apr 2012, at 2:20am, Brandon Allbery wrote:
> On Wed, Apr 4, 2012 at 19:08, Chris Jones 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 complete
> 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 mig
Am 05.04.2012 um 00:39 schrieb Jan Stary :
>>> 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...
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
On Wed, Apr 4, 2012 at 19:08, Chris Jones 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
On Wed, Apr 4, 2012 at 18:19, Jan Stary 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
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 a
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 confl
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
> 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 som
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...
> > 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.
> 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 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
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
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
Too many outright errors. Please.
On Wed, Apr 4, 2012 at 17:01, Jan Stary 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,
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."
>
> 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 m
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 inst
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 wr
-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
>>> `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.
sm
-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`
>
>
> "/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:
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 stonin
> 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 w
-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
-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 fo
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.
>
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
> /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?
I do have it completely override in my dot files, but I checked /etc/profile
and /etc/b
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
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 recomme
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:/us
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 expan
> 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'
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 an
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 plac
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 interferenc
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 ins
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 use
> 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 (espe
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.ma
> 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
Descript
> > 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
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, b
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 iss
On Wed, Apr 4, 2012 at 03:45, Saiwing Yeung 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
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 h
-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
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
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
> >> 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 thi
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
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
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.
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
-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 i
-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.
> 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
> direct
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
83 matches
Mail list logo
