GSoC idea for the binary issue (yet again)
fisksvett at gmail.com
Tue Mar 29 07:06:48 PDT 2011
Mar 29, 2011 kl. 9:26 AM skrev Anders F Björklund:
>>> 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...
If I'm getting you right, you think the Portfile for the binary archive contains unnecessary information.
Personally I don't think the size of the Portfile is the issue here really. 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?
More information about the macports-dev