[MacPorts] #43809: port selfupgrade to base v2.3.0 fails on G4
MacPorts
noreply at macports.org
Sun May 25 00:58:42 PDT 2014
#43809: port selfupgrade to base v2.3.0 fails on G4
--------------------------+--------------------------------
Reporter: paulccobb@… | Owner: macports-tickets@…
Type: defect | Status: new
Priority: Normal | Milestone:
Component: base | Version: 2.3.0
Resolution: | Keywords:
Port: |
--------------------------+--------------------------------
Comment (by ryandesign@…):
Replying to [comment:3 paulccobb@…]:
> Many thanks for coming back quickly with these two replies. I had
picked up a new Tcl because I needed >=8.5 for something I was working on,
but I can live with it being somewhere other than /usr/bin, at least as a
temporary workaround.
For example, you could install it using MacPorts. (`sudo port install
tcl`)
> I understand the point that you can't rely on any particular tlcsh path
and/or version in the early stages of the installation. Couple of quick
thoughts, for whatever they're worth:
>
> 1. Would it be possible to have the configure script do the search for a
tclsh as at present, BUT also do a quick sanity check of whether the Tcl
version is appropriate for the Mac OS version? If the check fails, exit
with a message explaining that the installation process needs Tcl
<major>.<minor> in /usr/bin (or wherever). Ideally the sanity check could
also consider architecture, and not try to use a 64-bit Tcl on a 32-bit
host (or vice versa).
It's probably not our job to verify that OS-provided software hasn't been
tampered with. I mean, that exercise would have no end. We either have to
move to being completely self-contained (which admittedly seems appealing
sometimes), or we have to assume that certain OS-provided components are
available.
But, it might not be unreasonable that we pick not the first tclsh found
but the first tclsh that actually works. I'm still not quite clear on why
we don't just use `tclsh` or `/usr/bin/tclsh`; not sure why we look for
`tclsh*`.
> 2. Could there be a way e.g. a config option to specify the Tcl
interpreter for use during the installation, so that if I know I've got a
suitable Tcl somewhere on my machine, I can tell the MacPorts installer
about it?
We do offer a lot of options like that already; from `./configure --help`:
{{{
--with-bsdmake=PATH Path to alternate bsdmake/pmake command
--with-bzip2=PATH Path to alternate bzip2 command
--with-cvs=PATH Path to alternate cvs command
--with-gnumake=PATH Path to alternate gnumake command
--with-gnutar=PATH Path to alternate gnutar command
--with-lzma=PATH Path to alternate lzma command
--with-make=PATH Path to alternate make command
--with-mtree=PATH Path to alternate mtree command
--with-open=PATH Path to alternate open command
--with-openssl=PATH Path to alternate openssl command
--with-rsync=PATH Path to alternate rsync command
--with-sed=PATH Path to alternate sed command
--with-svn=PATH Path to alternate svn command
--with-swig=PATH Path to alternate swig command
--with-tar=PATH Path to alternate tar command
--with-xar=PATH Path to alternate xar command
--with-xz=PATH Path to alternate xz command
}}}
So we could conceivably let the user pick the tclsh path as well. On the
other hand, the situation should never arise on OS X that tclsh doesn't
work. All versions of OS X that MacPorts works on have a working tclsh as
shipped by Apple; and until the just-released MacPorts 2.3.0, it was being
used every time you used the `port` command.
> I let the new Tcl go into /usr/bin only because that was the default for
the installer (think I used the package from ActiveState, but couldn't
swear to it), so I'd guess others will run into this same issue sooner or
later.
It is an error for you to install software into /usr/bin. That directory
is for Apple, not the user, to modify.
--
Ticket URL: <https://trac.macports.org/ticket/43809#comment:4>
MacPorts <http://www.macports.org/>
Ports system for OS X
More information about the macports-tickets
mailing list