Platform versions and Binaries

[Anders F Björklund]

Juan Manuel Palacios 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"?

Well, we have archivemode but that's only local so not very important

No - the main users of the code was for remote fetching, either inside
of MacPorts with the proposed patches or outside of MacPorts using
some kind of Package Manager like for instance Yum/APT-RPM/Smart...

> 	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?

Nope, not aside from RPM building. And actually installing those built
RPMs does require a system package that is yet to be decided anyway...
(i.e. the RPM providing all the org.macports.* virtual dependencies)

> 	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.

The alternative to noarch is of course storing the same package in both
i386 and ppc, the same goes for the alternative to fat architecture...
(store the same +universal one in both i386 and ppc depending on  
builder)

So neither of them is terribly important, just a little "optimization".

> 	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.

Not sure if platforms is anything more than an informational effort,
like you say the important things are decided elsewhere anyhow...
(the code - being manipulated in variants, and the packaging targets)

> 	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.

Not sure about the syntax, if you can make the above parse
it might be an idea (after all the platform variants work)
But I was more concerned about platform versions than arch.

Where I'm from OS and ARCH are different, but I'm flexible.
I was interested in how to split various releases, similar
to the "dist" problem we're seeing with Linux RPM packages.

i.e. how to separate darwin6/darwin7/darwin8/darwin9 binaries

--anders