Re: [gentoo-science] [PATCH 00/10] alternatives-2.eclass updates

[Reinis Danne <rei4dan@gmail.com>]

On Tue, Jan 21, 2014 at 12:04:43PM -0800, Sébastien Fabbro wrote:
> On Tue, Jan 21, 2014 at 11:26 AM, Reinis Danne <rei4dan@gmail.com> wrote:
> 
> > > * given the number of bugs, we should keep the linking to the reference
> > > names libraries, so we could eselect providers without re-compiling all
> > > reverse dependencies. We could do this in the open sourced providers by
> > > changing the soname of the libraries we compile, and in the binary ones
> > > (mkl,amcl...) with a link script generated library.
> >
> > Yes, this is ok and AFAICT it is like that now in the overlay.
> >
> >
> It is not. Let's take blas for example. Install openblas and
> blas-reference, then eselect blas reference. Then install lapack-reference,
> then remove blas-reference. You will have to re-install lapack-reference,
> because of a missing reference to librefblas.so. If openblas had the
> libblas.so soname and link, you would not have to. I'm actually not sure
> whether it is a side effect of our as-needed policy.
> 
> We need to change all blas ebuilds to make sure they have the same soname,
> and add to alternatives_for blas the libraries to link. For blas-reference,
> eigen, atlas and openblas, this is just a matter of a link flag. For acml
> and mkl, this is trickier, thus the gen_usr_ldscript from toolchain-funcs
> eclass idea. If the ldscript stuff is not much overhead, we could apply it
> to all.
> 
> Sebastien

Ok, that is different issue. The question is whether we want,
e.g., eselect blas be build time only or also runtime setting.

If we use provider specific sonames, then the program will use
whatever provider was selected at build time even if different
provider is set afterwards. Thus it is build time only setting,
with the caveat that package has to be rebuilt if selected
provider is removed (preserved-libs should catch this).

⬑ This is how it is now in the overlay.

If we provide generic sonames for alternatives (symlink or
ldscript), then program should use whichever provider is
currently selected. Thus it is runtime setting, with the caveat
that all packages can use only currently selected provider (user
has to keep track of selected provider).

Symlinks can be provided with the existing alternatives-2.eclass
if ebuilds choose to do so. Only change for generic pc file would
be not to point to selected provider's pc file, but to give
settings for generic libs (which is symlink to currently set). In
this case generic pc file generation should be added to eclass?

Is there any reason why it has not been used?

I don't know how often people actually do use specific providers
with different applications or how often they switch between
them?

As long as there are no programs with different preferred
providers, the generic libs would be ok. But if there are such
programs, then provider specific libs should be used. This could
already be done by picking provider specific pc file (and
optional USE-flags for providers in ebuilds).

AFAIK, benchmarking is the only use for generic libs (no need to
reinstall for every provider) and provider selection rarely
changes otherwise. Are there examples of opposite?

Could this be different for different alternatives (blas, cblas,
lapack, ...)?


Reinis