On Apr 15, 2010, at 6:19 PM, Ryan Schmidt wrote:
>> One solution is to install every port (and all of its dependencies) into its
>> own "chroot-like" subdirectory with all of the correct dylib linkages. So
>> each port you install might have its own personal copy of python built just
>> the way it needs it. Since disk space is cheap, all we need to do is come up
>> with binaries for each port+variant-combo, plus some other details here and
>> there.
>
> That sounds like a drastic departure from the way MacPorts works today. It
> sounds like a lot of work, for I'm not sure what benefit.
I beg to differ - it's not all that drastic a departure. There is a reason
that MacPorts stages through a depot today rather than just smashing everything
directly into ${prefix} out of destroot, and that reason is that we always
wanted the option of someday being able to "instantiate" a port in some
significantly more intelligent way. It was always clear from day one that
locations like /opt/local were significantly short on real-estate, with ports
needing to use various versioning conventions in their names ("tcl-8.1") to
avoid colliding as things got more full in there.
Wouldn't it be nicer if you could take a depot of installed ports + some
registration metadata and, from that, construct the appropriate user
environment such that simply typing "emacs" in a Terminal or ssh session still
worked, even though you might have 11 different versions of emacs, with various
options selected, actually in the depot? I think the user experience, and the
robustness of the system as a whole, should be seen as the primary objective
here, everything else being just an implementation detail for which a
surprising number of solutions already exist.
> Disk space isn't necessarily *that* cheap. For example, someone I was
> recommending MacPorts to recently balked at the requirement to install Xcode,
> since he did not have enough room to do so on the small drive that came with
> his MacBook Air.
If MacPorts shipped binary packages, this wouldn't be an issue either. I
shouldn't need the entire MacPorts infrastructure + XCode + distribution
tarballs + build scratch space just to be able to install one version of emacs
on my system, either, so we have a ways to go towards *any* sort of disk space
optimum here. :)
- Jordan
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
