Opened 8 years ago
Closed 4 years ago
#52128 closed enhancement (fixed)
ld64: don't add unsupported subports
Reported by: | mojca (Mojca Miklavec) | Owned by: | jeremyhu (Jeremy Huddleston Sequoia) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | Cc: | jmroot (Joshua Root), ryandesign (Ryan Carsten Schmidt), cjones051073 (Chris Jones) | |
Port: | ld64 |
Description
I mentioned this in comment:9:ticket:52091, but it's probably best to open a standalone ticket.
I would like to request removal of subports that are not supported on a particular OS. Not that this is a problem in practice (not sure why users would intentionally try to install an unsupported dependency), but it generates "red flags" and "annoying" emails from the buildbot. Below is a patch that needs some additional cleanup (which Joshua might be eager to do :) to remove non-existing variants from the conflict list. Another minor disadvantage is that conditions like
if {${os.major} < 14}
are currently repeated twice. It would be more elegant to be able to write that condition just once (potentially next to variant description like "(last version that works on Leopard)
")
Change History (6)
comment:1 Changed 8 years ago by mojca (Mojca Miklavec)
comment:2 Changed 8 years ago by mojca (Mojca Miklavec)
Replying to mojca@…:
I would like to request removal of subports that are not supported on a particular OS. Not that this is a problem in practice (not sure why users would intentionally try to install an unsupported dependency)
I was slightly wrong here. Unsupported variants (or subports for that matter) are also a problem for users who upgrade. This was a problem for ld64_latest +llvm33
or +llvm34
that triggered errors. It's probably not a problem in this specific case, but I still believe that it would be nice to only list and allow supported variants and subports.
comment:3 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Yeah, I was think that as well, but I left it alone since I wasn't sure how to safely do it.
This is consistent with the way we exclude full ports that are not supported on a particular OS (older gcc versions, etc), how should we exclude those?
comment:4 Changed 8 years ago by mojca (Mojca Miklavec)
Ryan recently brought it up on the mailing list and we didn't reach any conclusion yet. We'll probably have to extend base (or some portgroup) to cover that case. We should open a ticket for that if there isn't one open already.
At the moment an ugly "workaround" is to declare the port obsolete to avoid a build failure on the buildbot.
But I wouldn't argue that we should "keep this broken" just because there's another similar case that we don't know how to handle yet.
One option would be to add something like
if {${os.major} > 9} { stop-reading-this-file }
at the top of the Portfile
. This wouldn't work in cases where the main port is not installable, but a subport is. But let's move that part of discussion elsewhere.
comment:5 Changed 5 years ago by jmroot (Joshua Root)
Sometimes defining subports and sometimes not causes a number of problems. They should be defined everywhere and set known_fail to avoid buildbot failure messages.
comment:6 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | cjones051073 added |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Here is the preliminary patch:
Portfile
if {${os.major} >= 14} {pre-fetch {ui_error "$subport is not supported on Yosemite or later."error "unsupported platform"}}if {${os.major} <= 9} {pre-fetch {ui_error "$subport is not supported on Leopard or earlier. It requires the blocks runtime."error "unsupported platform"}}if {${os.major} <= 9} {pre-fetch {ui_error "$subport is not supported on Leopard or earlier. It requires the blocks runtime."error "unsupported platform"}}I intentionally kept the indentation of subports to minimize the diff.