> On Mar 24, 2019, at 4:05 PM, Mojca Miklavec <mo...@macports.org> wrote: > > On Sun, 24 Mar 2019 at 19:55, Craig Treleaven wrote: >>> On Mar 24, 2019, at 1:09 PM, Mojca Miklavec wrote: >>> On Sun, 24 Mar 2019 at 01:06, Craig Treleaven wrote: >>>> >>>> There are a number of ports that require a dependency to be installed with >>>> a non-default variant in order to build successfully. A short-coming of >>>> MacPorts is that this cannot be done progammatically >>>> >>>> When this is rolled out, we don’t want to make users think that a port >>>> will fail to build on their system when it is just a case of needing a >>>> non-default variant. >>>> >>>> However, I don’t know how to handle this cleanly. Perhaps we could parse >>>> the build log looking for the message that informs the user how to install >>>> the required variant. If found, instead of saying the build failed, we >>>> could indicate that the build was not attempted as the buildbot >>>> configuration could not support a successful install. >>> >>> I totally agree with your request, but this is completely out of scope >>> of the proposed app. This either needs a proper extension in the base, >>> or a workaround in mpbb, preferably the former. I believe a much >>> bigger general issue is reporting failure of port builds on OSes which >>> are know not to be supported (like: attempting to build the latest Qt >>> on 10.5). Again, this needs to be addressed elsewhere. >>> >> This issue hits very close to home for me. None of my MythTV ports, nor the >> hdhomerun-gui port, will build successfully on the buildbots. They never >> have. They *will* build successfully (on supported OS versions) if the >> proper variants are specified. >> >> If an unknowing potential user came to page for any of these ports and found >> nothing but failure messages for all of the buildbots, why on earth would >> they want to proceed to install the port? > > […] >> If we won’t expand the scope to handle this relatively common issue, we >> should at very least add some static text to the web page explaining that >> buildbot failures don’t mean necessarily mean the port will fail for a >> particular user. Even so, that is a very poor workaround. > > You could equally argue that users will see that ports don't fail, but > then they are buffled when they cannot install those ports on their > own machine. We should really really fix the situation in MacPorts. > Not the same at all. Now, if a user doesn’t specify the right variants they get a message that tells them what to do. Of course it would be better if that didn’t happen but this is the way things work, now.
> I would say: Don't kill the messenger. Just because one application > exposes some issues with MacPorts, it doesn't mean that the > application needs to be endlessly tweaked to hide those problems away. > We should no have failing builds on the buildbot, end of story. We > need to do everything to avoid failing builds, not to implement > explanations and workarounds on the wrong level. Note that we'll > probably have another student apply for a different project which > would, if selected, expose the exact same problem on a different page. > Should we implement those workarounds ten times? > As you said, people have looked at this problem and not found a workable solution. It may be a _long_ time before a “proper” solution is implemented. In the meantime, reporting these as failed builds *actively misinforms* users. When you say there will be the same problem “on a different page”, I don’t know what you mean. And if we can implement a workaround, why can’t we share it with this other page? Why would we have different pages reporting the same information? As I see it, all we have to do is search the appropriate log for the message that the active_variants PortGroup spits out when it detects a dep with the wrong variants. If found, we replace the text “Failed” with something like “Build not attempted”. And probably add a link to a page that explains why not. Clean and elegant? No. Hard to do? Again, no. > My argument is that we need to fix ports and base to avoid those > failures, not to explain them away. I don’t disagree. I guess I’m not as optimistic that this will be done quickly. Craig
