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

[Craig Treleaven]

Mojca:

I apologize for the length of this and for continuing to hammer on this issue but I think this is important.  I support the idea of a modern web app to bring together all the relevant information for a port that potential users of MacPorts need in order to assess if they want to install that software.  The results of the last buildbot runs is obviously valuable information. We would expect that virtually all ports would report successful builds on all the OS versions that they support.  As a maintainer, I wouldn’t leave a port in a broken state if I could possibly help it.  

A port that requires non-default variants is not known to be broken.  It did not fail to build—the buildbot was unable to attempt a build.  The vast majority of the time, it will build and install just fine for the user.  

> On Mar 24, 2019, at 4:05 PM, Mojca Miklavec <mojca at 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:
> […]
> 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?
> 
Myth requires a database backend and I’ve chosen mariadb 5.5.  I was pushed to add variants for mysql and different db versions.  That would have been a nightmare to support.  The perl dbd-mysql modules have to know where to find the db socket (AIUI) and therefore need a different variant depending on which database/version they are connecting to.  I’ve documented the required variants in the cookbook instructions on the MythTV wiki.

If I change the default variant for p5-dbd-mysql to suit me, I just push the problem to someone else.  I have no idea how many others are using this port and depend on it connecting to MySQL 5.7 by default.

BTW, mythtv-core.28, for example, doesn’t support OS X 10.8 or earlier.  It “fails” to build on those buildbots although it actually aborts before attempting the build.  I’m fine with that being reported in the web app as a failure since users of those OS versions will be informed that they can’t expect it to build for them.  I don’t want users on supported OS versions to see the exact same failure message.  “Unable to attempt” or “Not attempted” is actually what happened. 

More generally, a relatively common issue on MacPorts is X11 versus Quartz. Say the support library (such as gtk2) defaults to one (like +x11) but your package really needs the other.  Changing the default messes up others.  BTW, this would be a compelling use of installation statistics.  If we determined that, say, 80% of gtk2 installs are +quartz, then it would be a no-brainer to change the default.

> 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.
> 
It is outside my skill set and beyond the time I have available for MacPorts.  Our database ports and related accessors need someone with more knowledge of database admin than I have or want to have.  They are big, complex pieces of software and maintaining our fleet of ports is a serious commitment.  (Bradley, I miss you!)


> On Mar 25, 2019, at 2:56 AM, Mojca Miklavec <mojca at macports.org> wrote:
> 
> Dear Craig,
> 
>> As you said, people have looked at this problem and not found a workable solution.
> 
> Personally I never did spend any effort into fixing this, partially
> probably also because it doesn't affect any ports that I use or
> maintain.
> 
I believe there is a very, very old ticket on this issue but I can’t find it right now.

>> It may be a _long_ time before a “proper” solution is implemented.
> 
> You don't need a 100% perfect solution, but something that works.
> 
> What buildbot setup could do, is check which variants are required for
> a particular port. It could then perhaps install
>    p5.28-dbd-mysql +mariadb
> explicitly, which could at least work for direct dependencies; getting
> it to work correctly in a recursive way would be a bigger challenge.
> 
> Again, by far the easiest solution would be to fix ports in a way that
> no port requires a non-default variant to be active. You didn't yet
> answer my question: what prevents the dependencies of MythTV to change
> their default variants, so that your ports would work out of the box?
> 
See above.

>> In the meantime, reporting these as failed builds *actively misinforms* users.
> 
> This has been the case for years already.
> 
>> When you say there will be the same problem “on a different page”, I don’t know what you mean.
> 
> One of the project ideas is to make buildbot logs and summaries more
> useful, directly from the buildbot views:
>    https://trac.macports.org/ticket/55978
> While we could internally waste weeks doing ugly workarounds to make
> some ports artificially look pretty, I'm not going to ask developers
> of buildbot to implement workarounds to allow cheating and report the
> same build as both broken and successful at the same time. If you
> don't want your port to be reported as broken, fix either the port(s),
> the base, or the buildbot configuration.
> 
> An example of a buildbot configuration fix (that didn't actually take
> a lot of time to do) is that we no longer build obsolete ports (we
> used to do that in the past and got zillions of errors, in particular
> when modifying the graveyard ports).
> 
OK, I don’t get it.  You’re happy with a hack that avoids building obsolete ports but not with one that stops us from telling lies to users?  See following.

>> And if we can implement a workaround, why can’t we share it with this other page?
> 
> Because I don't want to implement "build is both working and broken at
> the same time" functionality in buildbot.
> 
I never said to report that the build is “working”.  

I suggested that we report that the build was not attempted which is exactly what happened.

>> Why would we have different pages reporting the same information?
> 
> It's not exactly the same. We are already reporting that "your" ports
> are broken, in both buildbot and on the GitHub interface (when you
> browse the commits). It's just that finding a particular port in the
> buildbot is currently almost a mission impossible, so as a consequence
> nobody knows which ports are broken and which ones work, except if you
> check your own commits immediately a few hours after doing the commit,
> or read the archives of build failures sent by buildbot. The
> improvements on the buildbot site are meant to make the buildbot's
> interface itself useful (which it currently isn't, except for checking
> the last few builds), while the standalone app would provide a
> plethora of other information (installation statistics, which ports
> are outdated, which ones are broken, which websites are broken, ...),
> just collected on one single place.
> 
The buildbot primarily supports port maintainers.  The port web pages are primarily to provide information to potential users.  We propose to feed a summary of the buildbot results to the port web page since that can help a potential user to determine whether they want to install a particular port or not.  It is wrong for that summary to say a port failed to build on the buildbot if that is not, in fact, what happened.  Especially when it is simple to parse the log and identify this relatively common circumstance.

>>> 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.
> 
> It needs someone to push for a fix, someone to come up with a decend
> idea for the fix, and someone to actually implement it (it could be
> the same person). If you take the first two tasks on you, even if you
> don't know how to code in the base yourself, there's a high chance
> that you'll get help with the last part. If nobody is pushing nor
> suggesting what to do, this will likely not be done as fast.
> 
> I'm just arguing that if we get a student working on the web app, I
> would prefer if he or she would perhaps spend time adding novel
> functionality, which could even be allowing user comments on each port
> (which you could use to explain why the port appears to be broken)
> rather than on something that should be fixed elsewhere. (I wouldn't
> mind the student spending time fixing that particular bug in buildbot
> configuration or in base if comfortable with the code, but I would
> definitely not want to demand from the student to fix this issue as
> part of the project. I'm pretty sure that we'll have plenty more
> serious problems that nobody is even aware of yet. And if it would be
> easy to fix in the web app, we'll gladly accept any patches.)

It is great that you bring a tonne of skills and experience and devote tremendous time and energy to MacPorts.  I really do appreciate your work.  I do what I can for MacPorts but I have a lot of other interests and commitments.   Since I have no formal computer science education, it probably takes me a lot longer to do simple things than it would take someone else.  Frankly, MythTV support of the Mac is failing.  There hasn’t been a Mac-based developer for the past 3 years or so.  The latest versions have glaring problems but there is no one with the C++ / Qt multimedia skills that has stepped up.  I put in a few weeks of work in Jan/Feb but the issues are far beyond me.

Craig