Platform versions and Binaries
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 ? 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. 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. --anders * http://trac.macports.org/projects/macports/ticket/12206
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/ ...
There is now an ${os.major} variable that can be used for this purpose, as in: ${os.platform}/${os.major}/${os.arch} http://trac.macports.org/projects/macports/changeset/26693 --anders
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
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
participants (2)
-
Anders F Björklund
-
Juan Manuel Palacios