Re: Updates about BLAS64
Hi,
I'm more confident on the proposed binary package layout.
Taking BLIS as an example, if we change the dependency-template [1] to
libblis2-openmp.symbols:
libblis.so.2 libblis2 #MINVER#
...
Then dpkg-shlibdeps would simply generate a dependency on libblis2 (meta),
which depends on one of libblis2-{openmp,pthread,serial}. This feature
is included in the BLIS/0.5.1-1 which I'm uploading shortly.
This looks neat, clear, free of historical burden.
Can anyone recommend me some more packaging examples in similar case?
(i.e. compiling the same library many times for different variants
where any two of the variants are compatible to each other but not
co-installable)
[1] deb-symbols(5)
On Tue, Dec 18, 2018 at 03:12:57PM +0000, Mo Zhou wrote:
> > > 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: