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
Regards,.... -jmpp