OpenBLAS binary packages

[Artur Szostak]

Hi David,

I'm not interested in OpenBLAS directly. But it is one of the dependencies of a dependency of a dependency of our software. Therefore we are affected. There is little I can do without cloning the stack of 3rd part dependency ports and modifying them. But that kind of defeats the purpose of using MacPorts in the first place to leverage on the package maintenance work done by the community.

Best regards.

Artur
________________________________________
From: David Strubbe <dstrubbe at macports.org>
Sent: 17 May 2019 04:24:23
Cc: Artur Szostak; MacPorts Users
Subject: Re: OpenBLAS binary packages

Hi Artur,

If you want BLAS available as a binary, why not use the built-in Accelerate framework (with the vecLibFort port if you are calling from Fortran) rather than OpenBLAS?

David

On Thu, May 16, 2019 at 11:57 AM Ryan Schmidt <ryandesign at macports.org<mailto:ryandesign at macports.org>> wrote:


On May 16, 2019, at 05:52, Artur Szostak wrote:

> I get and understand your concerns. Consider my comment as giving a data point from real world use in the wild. You already seem to be aware of the trade offs and consequences of technology choice and policy decisions related to package managers and how they are used.

I'm grateful for the feedback, but I don't know what else to say about this. The message I'm receiving from you is "fix all the bugs". We'd obviously love to do that. If we're not doing so fast enough, it's because we don't have enough people looking at the bug reports and fixing them; if you or anybody else can provide additional human resources to do that, that would be welcome.


> As for bug reports: We have made these as and where necessary. However, if you want earlier and better feedback, I can only suggest to make this process trivial for the end users, i.e. the goal would be the equivalent of one click reporting. This is hard to implement properly though, without exposing the project to abuse (e.g. spam etc.) and keeping end user security in mind. If done right however,  I think this could be a significant improvement to the project overall.

Specifics would be more helpful than generalities. What exactly should we be doing differently?

Currently, when a build fails, we print a message telling the user where the build log is located and how to report bugs to us. If you are suggesting that a bug should automatically be filed at this point, that would only further deplete our limited human resources by wasting our time on marking these automatic submissions as duplicates of other tickets. We already spend enough time on that with the current manual bug reporting system, because users are bad at identifying when their problem has already been reported by someone else and doesn't need to be reported again.

I don't think bug reports are a process that can usefully be automated. The user is expected to do some investigation on their own to discover whether this bug has been reported before, to read the notes of those previous reports, try out any fixes suggested in those reports, etc. In many cases a build fails not because of a bug in the port but because of a misconfiguration of the user's system; only the user can identify and correct such problems.