Re: Updates about BLAS64
On Tue, Dec 18, 2018 at 12:42:22PM +0100, Sébastien Villemot wrote:
> > src: openblas
> >
> > bin: libopenblas-base (meta)
> > deps: libopenblasX-openmp | libopenblasX-pthread,
> > bin: libopenblasX-openmp
> > conflict: libopenblasX-pthread
> > bin: libopenblasX-pthread
> > conflict: ...
> > bin: libopenblas-dev (meta)
> > deps: libopenblas-base
> > bin: libopenblas-openmp-dev
> > deps: libopenblasX-openmp
> > conflict: libopenblas-pthread-dev
> > bin: libopenblas-pthread-dev
> > deps: libopenblasX-pthread
> > conflict: libopenblas-openmp-dev
> >
> > bin: libopenblas64-base (meta)
> > [...omitted...]
> > bin: libopenblas64-dev (meta)
> > [...omitted...]
>
> I am not entirely convinced that meta-packages are needed. Isn't the
> "Provides: libblas.so.3" not enough? The main OpenBLAS package could
> actually remain the pthread version, as it is now, and there would be
> two new packages, for the OpenMP and the single threaded ones.
The metapackages also function as transitional dummy packages, since
the files have been moved into the -openmp, -pthread, -serial packages.
> > As we know, NEW packages such as BLIS are good candidates experiments
> > without risking to break existing packages such as OpenBLAS. So if the
> > way we compile BLIS is proved working, we can also apply it to OpenBLAS.
>
> That is a good idea. As a matter of fact, I think we are now too close
> from the freeze to start modifying the layout for OpenBLAS; let's wait
> for the Bullseye cycle.
BLIS is in NEW.
> > BTW, what is the "-base" (in libopenblas-base) supposed to mean?
>
> I don't even remember what it means, but it is clearly a legacy from
> the past. Ideally the package should be named "libopenblas0". But I did
> not bother with transitioning from one to the other, since it is rather
> tedious, with strictly zero benefit for users.
Then it's a good chance for us to get rid of it, when modifying the
package layout. We can avoid a transition if we turn the old pacakges
into meta packages. I still prefer my proposed package layout, i.e.
libopenblas0 (meta):
deps: libopenblas0-openmp | libopenblas0-pthread | ...
libopenblas-base (meta, because it cannot be safely removed):
deps: libopenblas0
libopenblas0-openmp:
conflicts: libopenblas0-pthread, ...
libopenblas-dev (meta):
deps: libopenblas0,
libopenblas-openmp-dev | libopenblas-pthread-dev | ...
libopenblas-openmp-dev:
conflicts: libopenblas-pthread-dev, ...
Such layout has several advantages:
1. compared to (libopenblas0 i.e. pthread version, libopenblas0-openmp),
the (libopenblas0-openmp, libopenblas0-pthread) layout is more
explicit and tidy.
2. we can control the default openblas implementation by adjusting
the dependency of libopenblas0 (meta) and libopenblas-dev (meta).
And maintainers of reverse dependencies won't have the headache to
choose one from (openmp, pthread, ...)
3. won't break packages that depend on libopenblas-base
Reply to: