Opened 14 years ago
Last modified 13 years ago
#27788 new enhancement
ports should ignore default +universal when universal archs mismatch
Reported by: | geekosaur | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Low | Milestone: | |
Component: | base | Version: | 1.9.2 |
Keywords: | arch | Cc: | |
Port: |
Description
A number of open ports bugs involve +universal
doing the wrong thing. In many cases, the problem is that configure.universal_archs
isn't consistent with universal_archs
in macports.conf
; this is especially troublesome when +universal
is specified in variants.conf
.
It occurs to me that, similar to variants.conf
variants being silently ignored if a port doesn't support them, +universal
in variants.conf
should be silently ignored when configure.universal_archs
doesn't match universal_archs
. The current behavior is correct if +universal
is explicitly specified, however.
Change History (3)
comment:1 Changed 14 years ago by geekosaur
comment:2 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)
Replying to allbery.b@…:
In many cases, the problem is that
configure.universal_archs
isn't consistent withuniversal_archs
inmacports.conf
Could you provide an example? configure.universal_archs
is created directly from macports.conf's universal_archs
, unless a port overrides it, which it should only do for a good reason.
comment:3 Changed 13 years ago by geekosaur
I thought that was the point; this bit me with such a port (although I don't at this point recall which). I do recall that it did have a good reason to override, but the universal-arch code doesn't seem to expect it to ever happen and doesn't respond sanely to it.
(I also just ran a find over the current ports tree, and am not seeing anything obvious. Either I filed this in response to a mailing list discussion, since I mentioned bug reports and not specific ports, or whatever it was has been fixed.)
This isn't actually the correct fix, just the expedient and backwards-compatible one. The correct fix is to promote "arch" to a first-class attribute and compare the port-supported archs with the requested archs; universal_archs and +universal would then be deprecated. Possibly this should use the intersection unless --enforce-archs is specified (by analogy with --enforce-variants).
However, this would be a radical change to MacPorts, and poses its own problems: how do you specify archs? A new variant-like syntax? How do you deal with arch-specific (or -dependent) port dependencies? The correct solution is not going to happen any time soon.