Re: Bring BLAS into pkgsrc, pt. II

["Dr. Thomas Orgis" <thomas.orgis%uni-hamburg.de@localhost>]

Am Sun, 21 Jul 2019 10:09:04 -0500
schrieb Jason Bacon <outpaddling%yahoo.com@localhost>: 

> 1. As I mentioned earlier, I think the variable names could be more 
> explicit to avoid confusion between what goes in mk.conf and what goes 
> in the pkg Makefile.

The variable with PKGSRC_ prefix goes into mk.conf. The others are for
the Makefile. That's what I understood from the earlier discussion (no
tradition of actually prefixing variables in package Makefiles with
PKGSRC_).

I agree that 'preferred' does not convey the actual meaning.

> PKGSRC_BLAS_PREFERRED => PKGSRC_USER_BLAS_ACCEPTED
> BLAS_ACCEPTED => PKGSRC_PKG_BLAS_ACCEPTED

I don't like four words in the variable name. Too verbose.

Right now we have those similar variables in the Makefiles:
$ find . -name Makefile | xargs grep _ACCEPTED | grep -v '#' | cut -f 2 -d : | cut -f 1 -d = | sort -u 
BDB_ACCEPTED
EMACS_VERSIONS_ACCEPTED
EMACS_VERSIONS_ACCEPTED+
KRB5_ACCEPTED
LUA_VERSIONS_ACCEPTED
MYSQL_VERSIONS_ACCEPTED
NODE_VERSIONS_ACCEPTED
PGSQL_VERSIONS_ACCEPTED
PHP_VERSIONS_ACCEPTED
PKG_APACHE_ACCEPTED
PKG_JVMS_ACCEPTED
PYTHON_VERSIONS_ACCEPTED
PYTHON_VERSIONS_REALLY_ACCEPTED
RUBY_RAILS_ACCEPTED
RUBY_VERSIONS_ACCEPTED

So, there is the example of two-word BDB_ACCEPTED and KRB5_ACCEPTED
that match BLAS_ACCEPTED. But the majority is three-word names, mostly
with VERSION in the middle. That's not the right word here, but we
could do

BLAS_ACCEPTED => BLAS_TYPES_ACCEPTED

Then the resulting BLAS_TYPE matches that wording. And actually, we can
use that for the user variable, too:

PKGSRC_BLAS_PREFERRED => PKGSRC_BLAS_TYPES

That may make more clear that it's about an exhaustive list of BLAS
implementations, not just a preference. So we'd have:

PKGSRC_BLAS_TYPES in mk.conf
BLAS_TYPES_ACCEPTED in Makefile
BLAS_TYPE, BLAS_LIBS, LAPACK_LIBS to be used by Makefile

OK?

> 2. I think we need to insert a step 1.5 into the process:
> 
> Test/patch all existing dependent packages against the new system before 
> committing the new blas and lapack packages.

Well, of course you need testing and fixing, but the import of
wip/lapack basically means a version update to 3.8.0 for dependent
packages. There is no fundamental change in what is provided. Checking
for one math/blas user that the change of now depending indirectly on
math/lapack causes no trouble makes sense.

What we need to check is the upgrade path. Will it cause trouble that
we now got liblapack.so.3 instead of liblapack.so.4? Things need a
rebuild. Or should be include a hacky symlink after all?

Hm, I am not at my workstation where my access key for pkgsrc-wip is
stored. I just noticed that wip/blas should have an empty PLIST. It's
not installing anything. I guess this causes no trouble as the check is
not done for the meta package, but it looks unclean.


> duplicate the affected packages in wip with necessary patches.

I am positive that we won't need proper patches for math/lapack or
math/blas usage. But of course one should check. We need people to
rebuild the packages, though. So … at least PKGREVISIONS?


Alrighty then,

Thomas

-- 
Dr. Thomas Orgis
HPC @ Universität Hamburg