GSoC idea for the binary issue (yet again)

[Anders F Björklund]

Jordan K. Hubbard:

>> I'm pretty sure that by "ports tree" he means dports/. Avoiding that
>> would be a win, as it does take a noticeable amount of time to initially
>> download it with rsync. (People have filed bugs because they thought the
>> installer had hung.)
> 
> Oh, totally agreed that you should never need a copy of the dports/ tree for package installation.  As Anders points out, the individual Portfiles are already inside the relevant packages, so in a sense the dports/ tree and the (someday) packages tree contain overlapping information.

Dumping the entire +PORTFILE is a crude hack for not knowing
which part of it would be relevant to encode as metadata...
All of that should be "elsewhere", even if it still uses Tcl
to run the scripts rather than convert those to "something else".

There's a +STATE file as well, which is even more ugly-looking.
Both of these should die, when making a binary package format ?
But the information itself is only overlapping/redundant if the
versions in the portindex and the pkgindex are always the same...

> I was talking purely about the MacPorts runtime, which I'm sure this project will also go a long way towards clarifying the boundaries of since separating things into package building and package consumption chains does have a way of forcing the issue, as I described in my earlier history lesson about how the *BSD tools actually evolved separately and were converged later.

If MacPorts runtime has a clear separation, there's no need
to avoid it. Even if wrapping it in Objective-C first, to
avoid looking at the Tcl directly (i.e. MacPorts.framework).
You would still need PortIndex, however. Or "Latest" links.

It doesn't even have to be included, since Tcl is provided
"by the system" just like the Foundation is for Objective-C.
Using GNUstep for a PureDarwin/FreeBSD platform, if needed.
So it's only the actual Tcl code, not the Tcl interpreter...

--anders