Platform versions and Binaries

[Juan Manuel Palacios]

	Rereading this initial post after Kevin committed r26693, with which  
we're now recording ${os.major}.

On Jul 1, 2007, at 8:10 AM, Anders F Björklund wrote:

> There is a upcoming problem that will occur with the binary
> archives/packages, in that most of the code currently only
> checks for ${os.platform} and ${os.arch} when looking for
> binaries, ignoring ${os.version} which might be important ?


	When you say this, what exactly are you referring to? Who is  
checking those variables and ignoring ${os.version}, base/src/port1.0/ 
portmain.tcl? Upon what operation? Or are you instead referring to  
"archivemode"?

	And with r26693 and ${os.major} in sight, don't we have more  
flexibility now to check for the major platform number we're  
interested in? From what I understand, r26693 just records $ 
{os.major} (e.g. Darwin *8*)... but we're not yet using it anywhere?

>
>
> e.g. Panther and Tiger will try to use the same binaries
> and archives, and ditto for FreeBSD STABLE and CURRENT...
>
>
> So we might need to include at least the major version in
> the paths used, so that they will become something like:
>
> darwin/9/i386/
> darwin/9/ppc/
> darwin/8/i386/
> darwin/8/ppc/
> darwin/7/ppc/
> freebsd/7/i386/
> freebsd/6/i386/
> freebsd/5/i386/
> ...
>
> This goes for /opt/local/var/macports/packages, and for
> remote fetching. It also goes for all RPM repositories.


	I guess having the "rpm" target share some code with "archivemode",  
if possible, would be good, to factor out things like platform/major/ 
architecture/others detection and not duplicate it in every single  
packaging target we support. I figure a package1.0/package_util.tcl  
TCL package would be in order....

	And I agree that we should further make the distinction of platform  
version when creating and storing these packages (archivemode,  
generated rpms, debs, etc...), I guess that we just need to hook up $ 
{os.major} properly. Platform architecture is already checked for but  
"noarch" should be included too.

	Not fully acquainted with how the "archive" target detects the  
necessary info, I'm thinking we could leverage the "platforms"  
declaration present at the top of every Portfile to make our  
decisions, through its extension with some keywords. True that  
"platforms" is there to announce on what platform(s) a given Portfile  
is meant to work on, and that the paths above are created at runtime  
to record what specific platform the package is built for... but my  
point is that precisely those two things should coincide at least up  
to a point.

	What I propose is we extend "platforms" as follows:

1) The current case:
	-) "platforms darwin"
	-) "platforms darwin freebsd"
		Means the port is declared to work both on darwin and freebsd, no  
architecture restriction
2) Proposed extensions:
	-) "platforms darwin ppc"
	-) "platforms darwin i386"
	-) "platforms darwin noarch"
		These architecture declarations would restrict what platform the  
port is allowed to work on when present. So, for instance, a port  
declared "darwin i386" would return with the nice error code  
suggested by Landon in one of his recent posts (c.f. http:// 
lists.macosforge.org/pipermail/macports-dev/2007-June/002015.html,  
return -code error "An error, here") when tried on ppc. A port  
declared "noarch" would have no restrictions but the keyword would be  
carried along with it when creating an archive/package. No  
architecture keyword (different from supplying 'noarch') would simply  
mean no restrictions and default to the host hardware (same for no  
os.major keyword).

	Some form of grouping would have to be thought of to be able to say,  
for example, 'darwin 9' *and* 'freebsd pcc' in a single platforms  
declaration in an unequivocal manner (that is, not mix keywords).  
Finally, the code currently making platform decisions in port1.0 and  
"archivemode" would have to be adapted to read this "platforms array"  
first and then fallback on defaults if no info is found.

	This approach, if technically sound and viable, would allow us to  
solve the "noarch" problem and to get rid of the dreadful "exit"  
calls maintainers put in some Porfiles to restrict what platforms the  
corresponding port is allowed to work on, all in one fell swoop! A  
Portfile declaring something like "platforms darwin 8" would see the  
port1.0 layer returning with an error code that would in essence  
implement Jordan's "ui_fatal" suggestion when attempted on Panther.


>
>
>
> Universal packages should probably go in a special place
> too, since they use the 10.4.u SDK and the "fat" arch ?
> Eventually one _might_ want to share "noarch"* packages
> between architectures, and maybe even between platforms.


	If what I propose above is viable, I guess 'universal' could be  
another valid keyword...


>
> --anders
>
> * http://trac.macports.org/projects/macports/ticket/12206


	Regards,....


-jmpp