[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