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

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.

comment:2 in reply to:  description 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 with universal_archs in macports.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.)

Note: See TracTickets for help on using tickets.