[MacPorts] #41796: binary package download ignores macosx_deployment_target set globally

[MacPorts]

#41796: binary package download ignores macosx_deployment_target set globally
------------------------+--------------------------------
  Reporter:  william@…  |      Owner:  macports-tickets@…
      Type:  defect     |     Status:  new
  Priority:  Normal     |  Milestone:
 Component:  base       |    Version:  2.2.1
Resolution:             |   Keywords:
      Port:             |
------------------------+--------------------------------
Changes (by ryandesign@…):

 * cc: william@… (removed)
 * cc: ryandesign@… (added)


Old description:

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

New description:

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

--

Comment:

 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.

-- 
Ticket URL: <https://trac.macports.org/ticket/41796#comment:2>
MacPorts <http://www.macports.org/>
Ports system for OS X