[49158] trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl

[Ryan Schmidt]

On Apr 9, 2009, at 06:24, Rainer Müller wrote:

> Ryan Schmidt wrote:
>
>> I still think rather than devote a lot of energy to this mechanism,
>> we should instead focus on building binaries, and let the server
>> merge them together -- or even let the user download both the powerpc
>> and intel binaries and have the user's macports merge them. Either
>> way, we wouldn't have to worry about figuring out how to let the
>> phases run multiple times, because the server would just run "port
>> install" multiple times instead.
>
> This sounds quite complicated. How would that work with the current
> image mode? Do merge on activate and split on deactivate?
>
> Are you planning to let the user install additional architectures time
> by time? Which would mean we need to track dependencies per
> architecture. Also we would need to ensure that no two different
> versions are merged together.

My original suggestion:

Two build servers per major OS:

Xserve G5: builds a port for ppc and again for ppc64
Xserve Xeon: builds a port for i386 and again for x86_64

Both build servers send both build products to a binaries server,  
which combines all four builds into a universal build, possibly using  
special instructions in the portfile for how to merge some files if  
automated lipo or diff, as in muniversal, won't work.

Someone pointed out that to allow the user to select any combination  
of variants, as we currently allow in macports.conf, the binaries  
server would have to create many different combinations of these  
(e.g. ppc+i386, i386+x86_64, ppc+ppc64+i386+x86_64, etc.). So that  
would take a lot of time to create and space to store. Some of the  
combinations might even be silly (e.g. ppc64+i386?).

On the other hand, my motivation for the above was so that a user who  
wants, say, all 4 archs only has to download a single package instead  
of 4 packages, which probably contain some amount of redundant  
information. That amount would vary widely by port. Some ports might  
have no shared files, or just a readme; others might have megs of  
documentation or even, in the case of some games, hundreds of megs of  
assets.

We could consider the idea of splitting ports with lots of shared  
arch-agnostic data into a separate port, which would be marked as  
arch-agnostic via a new syntax. This would cause some headaches for  
each port to switch to this layout.