Re: selfupdate failing under Leopard
On the other hand, if a user installs stuff in /usr/local/ after installing MacPorts it wouldn't help unless selfupdate (and/or port) also checked those paths so maybe it isn't feasible. The Cisco VPN client uses /usr/local, though it causes no problems. Comments?
So the 'problem' is only when the user installs some library in /usr/ local that macports uses and either that install is broken somehow or the user removes it.
It's good to make macports robust against mistakes, but at some point we probably have to realize that end-users are going to be able to configure their systems in ways that are broken, and we may or may not be able to do something about that specific broken-ness.
I agree. Especially since the woes of manually installed OSS is one if the problems MacPorts is trying to overcome. :) Is readline the main offender? I want to document this problem and though I think any non-MP software could potentially be a problem, I might mention the worst offenders as examples. What are others? Mark
On Nov 16, 2007, at 2:59 PM, markd@macports.org wrote:
I agree. Especially since the woes of manually installed OSS is one if the problems MacPorts is trying to overcome. :)
Is readline the main offender? I want to document this problem and though I think any non-MP software could potentially be a problem, I might mention the worst offenders as examples. What are others?
It's certainly the one I've seen people talk about most often. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
The use-case for readline in macports is quite small. I'm inclined to simply disable readline by default, which would eliminate this problem. All opposed? James On Nov 16, 2007, at 12:05 PM, Daniel J. Luke wrote:
On Nov 16, 2007, at 2:59 PM, markd@macports.org wrote:
I agree. Especially since the woes of manually installed OSS is one if the problems MacPorts is trying to overcome. :)
Is readline the main offender? I want to document this problem and though I think any non-MP software could potentially be a problem, I might mention the worst offenders as examples. What are others?
It's certainly the one I've seen people talk about most often. -- Daniel J. Luke +========================================================+ | *---------------- dluke@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/macports-users
On Nov 16, 2007, at 15:57, James Berry wrote:
On Nov 16, 2007, at 12:05 PM, Daniel J. Luke wrote:
On Nov 16, 2007, at 2:59 PM, markd@macports.org wrote:
I agree. Especially since the woes of manually installed OSS is one if the problems MacPorts is trying to overcome. :)
Is readline the main offender? I want to document this problem and though I think any non-MP software could potentially be a problem, I might mention the worst offenders as examples. What are others?
It's certainly the one I've seen people talk about most often.
The use-case for readline in macports is quite small. I'm inclined to simply disable readline by default, which would eliminate this problem. All opposed?
That might eliminate the problem of selfupdate not working in relation to the rogue readline in /usr/local, but it would not fix, for example, ticket 12040, in which db44 fails in weird ways if a rogue readline is present. I believe other ports can fail in these ways as well. http://trac.macports.org/projects/macports/ticket/12040 I would prefer a solution that causes MacPorts to scream and shout if a readline is present in /usr/local.
On Nov 16, 2007, at 2:27 PM, Ryan Schmidt wrote:
On Nov 16, 2007, at 15:57, James Berry wrote:
The use-case for readline in macports is quite small. I'm inclined to simply disable readline by default, which would eliminate this problem. All opposed?
That might eliminate the problem of selfupdate not working in relation to the rogue readline in /usr/local, but it would not fix, for example, ticket 12040, in which db44 fails in weird ways if a rogue readline is present. I believe other ports can fail in these ways as well.
http://trac.macports.org/projects/macports/ticket/12040
I would prefer a solution that causes MacPorts to scream and shout if a readline is present in /usr/local.
Hi Ryan, I'm still willing to be convinced otherwise, but I did end up putting in code to disable by default the readline support. Your point that users may experience the problem elsewhere is good, but I'm most concerned about them having a good experience with MacPorts, and this is a problem that quite a few face out of the box. The return for having readline is very small, as readline is really only useful if port(1) is run in interactive mode, which is not a very common thing for people to do, and so we end up causing a lot of pain (for others and for ourselves) for a feature that doesn't give much back. James
participants (4)
-
Daniel J. Luke
-
James Berry
-
markd＠macports.org
-
Ryan Schmidt