Re: Deciding on wich variant(s) of OpenBLAS library to install

[Jason Bacon <outpaddling%yahoo.com@localhost>]

On 03/25/18 16:09, Dr. Thomas Orgis wrote:
> > 2. The ability to override the default for individual dependent packages
> Please clarify: Do you mean the packager shall be able to override a
> default the user/admin set? Or do you mean that the user/admin shall be
> able to specify a per-package BLAS choice different from the default
> (be it pkgsrc default or set in local mk.conf)?
I think both the packager and the end user should have the ability to 
choose.

Many end-users could be scientists who are not particularly 
computer-savvy and
just want an easy way to install their programs.  They may not be aware 
of bugs or compatibility
issues with a particular BLAS implementation, and the package maintainer 
could save a lot of
end-users from struggles by locking a package into a particular 
implementation that works well
for that package.

I'm not sure this is really an issue anyway.

I'm not sure how we would prevent a packager from selecting a particular 
BLAS package instead
of using the mk facilities provided.  It would seem that we would have 
to go out of our way and do
extra work in order to be Draconian about it.  I think it's better to 
provide a simple framework to
allow for interchangeable BLAS implementations and assume there will be 
valid reasons not to use
it in some cases.
> My priority is to have consistent BLAS by default and override by user
> where desired. I know that we have some disagreement regarding
> compatibility of BLAS packages for dependent packages … but since the
> BLAS-using packages are few, we can check if they work with the default
> (serial openblas, I presume) and leave possible troubles to the
> conscious user who sets a different default. We are talking abount
> scientists who are used to messy situations;-)
I think BLAS-using packages are few at the moment because pkgsrc does 
not have good
BLAS support.  The potential BLAS-dependent packages are many, and once 
OpenBLAS, et. al.
are committed, there will be more motivation to use pkgsrc for deploying 
BLAS-dependent software.
> > Take a look at FreeBSD ports, where Netlib, Atlas, and OpenBLAS are all
> > available.  It's not an ideal solution, and issues do arise, but they're
> > solvable and it's working well in the end.
> And I point at the Debian way, that has all BLAS installed, but
> normally only one in use. We should have the best of those worlds.
>
> I might actually be able to start working on this now …
I trust you to implement a reasonable solution.  If we run into any 
problems, we'll learn from them
and make improvements.  Since we're starting with a small number of 
dependent packages, there's
little reason to fear changes down the road.

At this early stage, I would simply urge some basic design principals: 
Allow the packager and
end-user as much freedom as possible and aim for a framework that's 
simple and easy to
maintain.

So I vote to get something started, experiment with it, and let it 
evolve from what we learn.

Cheers,

    JB