Changes between Initial Version and Version 2 of Ticket #41796
- Timestamp:
- Dec 13, 2013, 5:08:42 PM (11 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #41796
- Property Cc ryandesign@… added
-
Ticket #41796 – Description
initial v2 1 As evinced in https://trac.macports.org/ticket/41589 , the binary packages appear to be built with the macports variable {{{macosx_deployment_target}}} set to {{{10.9}}} (or unset, and built on a 10.9 machine).1 As evinced in #41589 , the binary packages appear to be built with the macports variable {{{macosx_deployment_target}}} set to {{{10.9}}} (or unset, and built on a 10.9 machine). 2 2 3 3 When a user has set this variable to have a different value, but is still allowing binary ports, the binary ports are downloaded even though they were built with a different value to that specified globally by the user in macports.conf. Thise leads to incompatibilities such as those mentioned above. … … 5 5 Possible solutions to this: 6 6 7 •Force {{{buildfromsource always}}} if {{{macosx_deployment_target}}} is set to other than the current system's OS version (this is very easy and has an overhead only for the user)8 •Include the macosx_deployment_target as part of the request data when fetching a binary package (this is harder, and could lead to a proliferation of binary packages, one for each possible value of {{{macosx_deployment_target}}}7 * Force {{{buildfromsource always}}} if {{{macosx_deployment_target}}} is set to other than the current system's OS version (this is very easy and has an overhead only for the user) 8 * Include the macosx_deployment_target as part of the request data when fetching a binary package (this is harder, and could lead to a proliferation of binary packages, one for each possible value of {{{macosx_deployment_target}}} 9 9 10 10 Either way, the current situation leads to ports being installed which do not honour the value set in {{{macports.conf}}}, which is clearly a bug.