GSoC idea for the binary issue (yet again)

[Anders F Björklund]

Erik Österlund wrote:

>>> 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...
> 
> If I'm getting you right, you think the Portfile for the binary archive contains unnecessary information.

Yes. Specifically, a bunch of build-time stuff (and Tcl).

For a binary package format, it would be "better" to have
the metadata available in some kind of "markup" instead.
(even if it's just a silly text format, and not real ML)
That way you can read it from any language, not just Tcl ?

i.e. read +COMMENT/+DESC/+CONTENTS, instead of +PORTFILE

> Personally I don't think the size of the Portfile is the issue here really.

It's not.

> Seems like a non-issue. I think getting it up and running with some kb irrelevant information is perfectly fine. What happened to "let's not think of the ultimate solution and get something done instead"?! Or am I missing something?

It still applies, so feel free to add a Portfile parser
and read the +PORTFILE rather than extending +CONTENTS.

And I'm not talking about the need to run Tcl scripts,
but the need to run the Tcl portfile to parse metadata...

--anders