Opened 10 years ago
Last modified 3 years ago
#41796 new defect
binary package download ignores macosx_deployment_target set globally — at Version 2
| Reported by: | gallafent | Owned by: | macports-tickets@… |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | base | Version: | 2.2.1 |
| Keywords: | Cc: | ryandesign@… | |
| Port: |
Description (last modified by ryandesign (Ryan Carsten Schmidt))
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).
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.
Possible solutions to this:
- Force
buildfromsource alwaysifmacosx_deployment_targetis set to other than the current system's OS version (this is very easy and has an overhead only for the user) - 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
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.
The workaround is to add a buildfromsource always line to macports.conf then rebuild your system with sudo port -n upgrade --force installed (for example).
Change History (2)
comment:1 Changed 10 years ago by gallafent
| Cc: | william@… added |
|---|
comment:2 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)
| Cc: | ryandesign@… added; william@… removed |
|---|---|
| Description: | modified (diff) |
There are four buildslaves at this time, one each for 10.6, 10.7, 10.8, and 10.9, each building binary packages for use only on that operating system. Yes, macosx_deployment_target is unset in their macports.conf files; in general, their macports.conf files are almost completely (or likely even completely) default.
Yes, there are any number of changes the user could make on their system—from the settings in their macports.conf to the variants they use to the version of Xcode they use—which would make using the MacPorts binary packages unadvisable; you've found another one of them. If we do anything to fix this, it should be to disable binary packages when macosx_deployment_target is non-default. Or we might do nothing, since there's no particularly good or particularly well-supported reason why a user should ever change macosx_deployment_target within MacPorts.
Cc Me!