On Jul 11, 2013, at 01:14, Clemens Lang wrote: > On Wed, Jul 10, 2013 at 09:54:30PM -0500, Ryan Schmidt wrote: >> There seem to be two ideas going on here: >> >> 1. ship a known good version of Tcl with MacPorts so that we avoid >> bugs in versions of Tcl on specific versions of OS X >> 2. use Tcl 8.6 so that we can simplify some of MacPorts base >> >> To satisfy (1) we can bundle Tcl 8.5 with MacPorts. Later, to satisfy >> (2), we could work on replacing the try/catch usage in MacPorts with a >> Tcl 8.6-compatible version. > > Yes, we could work on bundling Tcl 8.5 with MacPorts first. But if we're > going to do the bundling anyway, we might also just go for the latest > and greatest, if it isn't a huge hassle to do so (and I wouldn't say ~30 > source code modifications count as a huge hassle).
I think we'd be less likely to introduce strange breakage by starting out with Tcl 8.5, which is the version everyone on Snow Leopard, Lion and Mountain Lion is already using with MacPorts today. It's probably helpful to break goals down into the smallest possible independent tasks. Bigger monolithic goals tend to get postponed. >> I assume we would: >> >> * ship a binary of MacPorts (like we already do) and a binary of Tcl >> in the package download >> * ship the source of MacPorts (like we already do) and the source of >> Tcl in the source download > > Which in turn means we would build Tcl from source during selfupdate, > right? I suppose so. But there's still the idea of self-hosting MacPorts, where MacPorts would come with the MacPorts port pre-installed and the selfupdate mechanism would be just a thin shim around updating the MacPorts port: https://trac.macports.org/wiki/SummerOfCode#self-management How would MacPorts itself having dependencies (on Tcl or cURL or whatever) affect that idea? _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
