[GSoC][Binaries support] Architecture

[Jordan K. Hubbard]

On Mar 26, 2011, at 12:42 PM, Bradley Giesbrecht wrote:

>> Such that the user can install any possible variation of the package?   I would argue, again, that this is a premature challenge to be taking on because of the complexity (and added build time) and, to start with, you should just build "sundae" and leave the variants as a second (or possibly never) step.
> 
> How about building ports with default variants, and binary requests for non-default variants would add a new build+variant to the build queue?
> So user demand creates build variants.

That's one idea that has also been kicked around in the past, sure.  You could easily treat "pkg install foo +bar +baz" as, essentially, a message to the package server that "foo+darwin_11+x86_64+bar+baz" (some variants being implicitly passed in) was being requested.  If the server can find that particular package in its cache, great, the bits start streaming back immediately.  If not, it builds that specific package on demand and, assuming success, hands the bits back after what simply seems like a much longer delay.  This also implies that pkg(1) and the package server back-end have a way of exchanging both data and status information out of band such that the user of the system can be told when a package is being created on demand and to just hit ^C if it's too long a wait.   But yes, one really nice feature of this is that you get to find out what variants of the packages are actually popular vs merely possible.

>> # xar -t -f /opt/local/var/macports/packages/darwin_10/x86_64/ccal/ccal-0.6_0.x86_64.xar 
>> +COMMENT
>> +CONTENTS
>> +DESC
>> +PORTFILE
>> +STATE
>> opt
>> opt/local
>> opt/local/bin
>> opt/local/bin/ccal
> 
> Shouldn't the prefix go away?

Presumably yes, though only because it would save space to state the prefix once (which is what you can do in +CONTENTS) and list all the file paths as relative from there.  As to whether a package is actually relocatable or not, and therefore should have a hard or soft prefix, is a different question.  This particular port would probably work fine if unpacked in /usr/local, but I can think of a good many more which would fail to function or lose certain runtime functionality if unpacked anywhere other than /opt/local.

- Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20110326/35110f5c/attachment.html>