Dependencies on non-default variants (was: GSoC 2019 [Collect build statistics])

[Mojca Miklavec]

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?

Please note that HomeBrew dropped *ALL* variants from *ALL* of their
maintained packages, saying something like: "We may discuss which
features will be turned on, or which library will be linked, but we
won't discuss adding back any of those options."

I now checked the first two random MythTV ports, which basically boils down to:

require_active_variants qt5-mysql-plugin mariadb55
require_active_variants p${perl5.major}-dbd-mysql mariadb
require_active_variants ${pymodver}-mysql mariadb55

out of which only the second one provides the wrong default variant,
and that port doesn't have the maintainer. Neither do any of the mysql
packages have any maintainer at the moment.

My first question is: why exactly does p5-dbd-mysql need a different
default variant?

My second question / suggestion: please try to take over maintenance
of the packages that you depend on and turn them into a shape that
will make them more generally usable.

> 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.

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?

My argument is that we need to fix ports and base to avoid those
failures, not to explain them away.

> I’m not familiar with the 2015 work.

It was about using a library to resolve dependencies in a
"mathematically correct way". If this was finished, "port install foo"
would automatically install the dependencies with the correct variant,
among others.

> ‘port’ now returns zero for successful completion. Have we considered having port set a return code that indicates the general class of an unsuccessful operation?

I'm not aware of that, but that discussion would call for a different
ticket or different topic on this mailing list.

Mojca