Opened 17 years ago

Closed 15 years ago

#12170 closed defect (fixed)

BUG: the default +universal variant shouldn't appear in ports where we know it won't work

Reported by: ryandesign (Ryan Carsten Schmidt) Owned by: jmroot (Joshua Root)
Priority: Normal Milestone: MacPorts 1.7.0
Component: base Version: 1.4.42
Keywords: Cc:
Port:

Description

This is a follow-up to #12137 in which I experienced this problem:

$ sudo port install glitz +universal
Error: Error executing universal: Default universal variant only works with ports based on configure
Error: Unable to execute port: Error evaluating variants

Turns out it's not complaining about the glitz port, which does use configure, but rather about the XFree86 port, which doesn't use configure. I'm not even using XFree86; I'm using Apple's X11.

I worked around the problem for XFree86 by removing its +universal variant in r26296, since it was nonfunctional anyway, but the fundamental problem remains: MacPorts made the default +universal variant available to XFree86, although we already know the default +universal variant only works with ports that use configure. I say that, for ports that say "use_configure no", MacPorts shouldn't give them the default +universal variant. This would have avoided the problem I experienced.

Attachments (1)

universal-noconfigure.diff (6.3 KB) - added by jmroot (Joshua Root) 16 years ago.
proposed fix

Download all attachments as: .zip

Change History (14)

comment:1 Changed 17 years ago by kballard (Lily Ballard)

Resolution: duplicate
Status: newclosed

Duplicate of #12169, which you filed 4 minutes prior. WTF, man?

comment:2 Changed 17 years ago by ryandesign (Ryan Carsten Schmidt)

Resolution: duplicate
Status: closedreopened

Not a duplicate of #12169, though I did copy and paste the initial paragraphs. The situation from #12137 is the catalyst for filing both for #12169 and this bug, but they are separate bugs which require separate solutions. This issue is for the fundamental problem in base the universal variant is given to ports for which we should already know that it won't work, which caused the problem I experienced in #12137, which could have been avoided if base were more selective about which ports it makes the universal variant available to.

comment:3 Changed 17 years ago by ryandesign (Ryan Carsten Schmidt)

Currently, when users use "port info foo" they will see a universal variant available for most ports. Users may rightly assume that this means that they can use +universal to build the port, but this will fail and annoy them if the port does not use configure. This will be even more noticeable to users who add +universal to their default variants. Basically, +universal is broken by default for ports that do not use configure. My request in this ticket is to fix this so that "universal" does not show up in "port info foo" if the port says "use_configure no".

comment:4 Changed 17 years ago by jmpp@…

Milestone: Needs developer reviewMacPorts base bugs

Milestone Needs developer review deleted

comment:5 Changed 17 years ago by nox@…

Priority: ExpectedNormal

comment:6 Changed 16 years ago by jmroot (Joshua Root)

Cc: jmr@… added; ryandesign@… removed
Milestone: MacPorts base bugsMacPorts 1.6.1

The attached patch avoids defining a universal variant in the cases where it won't work, instead of making a variant that throws an error. Nominating this for the upcoming release.

comment:7 Changed 16 years ago by jmroot (Joshua Root)

Sorry, the patch doesn't work properly. Should have known it would already have been done if it were that easy.

comment:8 Changed 16 years ago by jmroot (Joshua Root)

OK, new patch attached, which seems to do it right. If there are nicer ways to achieve what it does, I'm all ears.

comment:9 Changed 16 years ago by raimue (Rainer Müller)

Instead of platform_is_macosx, can't you use this?

if {[info exists variations(macosx)] && $variations(macosx) == "+"}

I don't like duplicating this check.

comment:10 in reply to:  9 Changed 16 years ago by jmroot (Joshua Root)

Replying to raimue@macports.org:

Instead of platform_is_macosx, can't you use this?

if {[info exists variations(macosx)] && $variations(macosx) == "+"}

I tried that, but it didn't seem to work. I think the variant isn't set any more at that point if the portfile doesn't contain a platform macosx block.

Changed 16 years ago by jmroot (Joshua Root)

Attachment: universal-noconfigure.diff added

proposed fix

comment:11 Changed 16 years ago by jmroot (Joshua Root)

Patch updated: replaced the redundant platform_is_macosx procedure with a new os.universal_supported variable, and deleted an unreachable error condition from the universal variant.

comment:12 Changed 16 years ago by jmroot (Joshua Root)

Cc: jmr@… removed
Owner: changed from macports-tickets@… to jmr@…
Status: reopenednew

Patch is working well in my testing. Committed to trunk in r36764. Leaving this ticket open until the patch is merged into the 1.6 branch, or retargeted to a later release.

comment:13 Changed 15 years ago by jmroot (Joshua Root)

Resolution: fixed
Status: newclosed

Marking fixed since 1.6.1 has turned into 1.7.

Note: See TracTickets for help on using tickets.