Bug 1574517

Looking at the openblas spec file shows that the pkgconfig file is actually deleted on purpose:

# Get rid of generated pkgconfig file
rm -rf %{buildroot}%{_libdir}/pkgconfig

Is there some specific reason why the pkgconfig file can not be packaged?

Exactly because there are multiple flavors and supplying a pkgconfig file gives you the false impression that there's only one variant.

The use of a pkgconfig file is rather limited, since it's easier to just add -lopenblas{,p,o}{,64{,_}} to your link command than patch in the correct pkgconfig file. This is IMHO simpler than having six different pkgconfig files for the different variants, which can silently give you the wrong result. (It's not obvious the default version should be the sequential one.)

Well, I can see the complications, but to be honest I don't see a problem with choosing one specific version to be the default. I personally prefer the serial one (but choosing the same one as is the default upstream build, i.e. the threaded openblas with the 32bit interface (openblasp library) should be also reasonable). I think the openblasp library is the one which is lately used also by other Fedora packages which need BLAS (e.g. numpy), so this would play in favor of this choice as well.

I'm not sure how such default config could give you silently wrong result? Sure, you could get suboptimal performance, but it should be better than nothing.

From a perspective of a developer who wants an app to autodetect libraries in a reasonable way, the pkgconfig it the most common tool, i.e. there is a reason it was added upstream.
By not including the .pc file, packages which depend on pkgconfig to detect openBLAS (and since upstream has it now it is a reasonable assumption that the distros will pick it as well) will not be able to detect it at all.

The pthreads version is the wrong one to use, since it doesn't play nice with OpenMP applications, which are nowadays pretty much ubiquitous in numerical programming.

I will defer to you judgment what the default version should be, but if the pthreads and openmp does not play well together then maybe the serial version should be the default choice.
It would also make sense from the point of view that when you pass -lopenblas to your flags on Fedora ATM, you will link with the serial version, hence it would make sense for the pkg-config --libs openblas to return the -lopenblas flag

I would really prefer to have one .pc file for each version, similar how it is done for example with fftw which have multiple fftw{,f,l,q}.pc files. However fftw suffixes are standard upstream naming, while OpenBLAS suffix naming is unfortunately distro dependent as far as I can see. Hence the benefit for app portability would be probably minimal there. I could bring this up upstream though to see if they can come up with some consistent library versions naming...

But even if the above is not solved, having one default .pc file does not IMO hurt anything.

I'm reopening this bug for a next round of discussion, since there were further related improvements upstream.

Specifically since this commit:
https://github.com/xianyi/OpenBLAS/commit/67912943120c9488b53a8d1dcf645f6a3b950475
the OpenBLAS .pc files now contains majority of the build options in the openblas_config variable. Hence it should be now IMO possible to have a really distro independent openblas detection.

E.g. if each openblas flavor had its .pc file, you could just do "pkg-config --list-all | grep openblas" to detect all installed flavors and then you can obtain the build options with "pkg-config --variable openblas_config openblas{,p,o}{,64{,_}}" for each detected library and select the one you prefer based on the output.

This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora  'version' of '27'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 27 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '29'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 29 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Re-opening this older issue, because the situation seems to be a bit different now.


Summary of the current state
----------------------------
One thing that was already mentioned above (and closed by F29 EOL, not deliberately) is that openblas upstream and other distros now provide openblas.pc.

What's maybe more interesting is that some packages look for the openblas.pc and fail to build when not found -- one example is "pip install scipy" (on ppc64le arche for which the upstream does not build a wheel package):

# pip install scipy
...
  Run-time dependency openblas found: NO (tried pkgconfig and cmake)
  
  ../../scipy/meson.build:120:0: ERROR: Dependency "openblas" not found, tried pkgconfig and cmake

But what's maybe the biggest change is that we now have flexiblas in Fedora, that is the suggested way to link with *blas: https://fedoraproject.org/wiki/Changes/FlexiBLAS_as_BLAS/LAPACK_manager

And this flexiblas-devel ships four *.pc files: flexiblas.pc flexiblas64.pc flexiblas64_api.pc flexiblas_api.pc

So, I believe that the existence of four files in flexiblas-devel addressed the issue of which variant the pkgconf file should link to -- we can mimic the behavior of flexiblas and have more openblasX.pc variants.

Now, the most interesting piece -- components in Fedora are supposed to link with flexiblas library instead of openblas directly. Should this be done by packages outside of distro as well? Because there is an option to just have a symlink flexiblas.pc -> openblas.pc which could make the trick. However, that would likely bring some unwanted non-transparency that would be misleading. 


Recommendation what we can do
-----------------------------
* ship openblasX.pc files in openblas-devel
* verify that this change does not make some package in Fedora to link with openblas directly (all packages still link with flexiblas; i.e. openblas-devel is not required by any srpm -- although I'm not sure we can avoid this)
* submit a proposal to scipy to prefer flexiblas.pc if it exists

Any thoughts?

A PR for the simplest way how to address it -- just ship one variant of openblas.pc:
https://src.fedoraproject.org/rpms/openblas/pull-request/5

*** Bug 2128488 has been marked as a duplicate of this bug. ***

+1 to ship openblasX.pc files in openblas-devel

Since FlexiBLAS must used as default, the package config file should just symlink to the flexiblas version.

(In reply to Susi Lehtola from comment #15)
> Since FlexiBLAS must used as default, the package config file should just
> symlink to the flexiblas version.

That did solve my problem.

I would like this issue solved too.
I attempted to build this project https://github.com/borisdayma/dalle-mini.
Which fails because meson fails to find openblas pkg-config entries.
I inspected the Debian package of openblas.
They seem to have multiple conflicting provider packages but they do contain pkg-config entries.
https://packages.debian.org/sid/libopenblas-dev.

This is now a relevant concern for both SciPy and NumPy, as we move towards building with Meson. From our perspective, an opinionated choice of which openblas.pc to provide would be preferable over the current situation.

In accordance with
https://fedoraproject.org/wiki/Changes/FlexiBLAS_as_BLAS/LAPACK_manager

refiling against flexiblas. Please include pkgconfig wrappers to link in flexiblas by default instead of openblas etc.

We *could* ship symlinks with flexiblas, but I'm a bit hesitant. This would solve one particular problem, but what if the package decides that ATLAS is the new default? What if they use cmake instead? What if they hardcode the flags? Laugh now, cry later. A permanent solution would be exposing a mechanism upstream to select another library. E.g., this is possible with Numpy as follows [1]:

$ NPY_BLAS_LIBS="-lflexiblas" NPY_CBLAS_LIBS="" NPY_LAPACK_LIBS="" pip install numpy

Scipy does provide a mechanism [2], but there's currently no way of passing down those parameters through pip [3]. They could honor Numpy's env vars, BTW. And if we are talking about a simple symlink, the workaround is clear, and you don't need either flexiblas nor openblas to do it for you:

$ ln -s /usr/lib64/pkgconfig/flexiblas.pc openblas.pc
$ PKG_CONFIG_PATH=$PWD pip install scipy

[1] https://numpy.org/devdocs/user/building.html#accelerated-blas-lapack-libraries
[2] https://numpy.org/devdocs/user/building.html#blas
[3] https://github.com/scipy/scipy/issues/16308

(In reply to Iñaki Ucar from comment #21)
> And if we are talking about a simple symlink, the workaround is clear,
> and you don't need either flexiblas nor openblas to do it for you:
> 
> $ ln -s /usr/lib64/pkgconfig/flexiblas.pc openblas.pc
> $ PKG_CONFIG_PATH=$PWD pip install scipy

Good suggestion. Closing

>> $ ln -s /usr/lib64/pkgconfig/flexiblas.pc openblas.pc
>> $ PKG_CONFIG_PATH=$PWD pip install scipy

> Good suggestion. Closing

This is *not* a good suggestion. Requiring manual symlinking is a non-solution that no end user or developer wanting to build from source is going to hit upon unless they find this bug report. Susi, you seem to be repeatedly closing this as "not a bug", but it looks like you are alone in that opinion, with quite a few folks asking for adding the pkg-config file. Please stop closing this issue.

Let's start with what the problem is. There are different personas that may want to build from source:
1. A Fedora packager, building things in Fedora itself. There's no problem there, the answer is: use Flexiblas. 
2. End users wanting to build something from source. E.g. for SciPy: `pip install scipy --no-binary` (or simply `pip install scipy` on platforms for which there are no wheels). There's many other projects who may want OpenBLAS though, this issue is not specific to SciPy/NumPy or even Python packages (OpenBLAS is the default for R and Julia as well).
3. Maintainers/contributors to a package like SciPy, who also have to build from source.

The main difference between (2) and (3) is that for (2) things really should work without end user intervention; for (3) that'd be nice, but build instructions can contain an extra step. Other than that they're equivalent. This "it must work without end user intervention" is important. Not having that is a recipe for bug reports and frustrated users. So a "just do this symlink step or set this environment variable to make things work on Fedora" is bad.

Flexiblas is Fedora-specific, so it's not a good solution for using as default. Each distro does something else here, e.g. Debian uses `update-alternatives`, Gentoo uses `virtual/blas` and `virtual/lapack` (see https://wiki.gentoo.org/wiki/Blas-lapack-switch), and conda-forge uses `conda install "blas=*=openblas"` (see https://conda-forge.org/docs/maintainer/knowledge_base.html#switching-blas-implementation). There's no good way of building such distro-specific mechanisms into Meson, or NumPy, or SciPy.

So we get back to: please provide pkg-config files. pkg-config is the best method of dependency detection and consumption for shared libraries, the alternative is basically to manually search through a set of standard directories for a .so with the right name, and then hope it contains what you need. What should be provided at least is `openblas.pc` for LP64 and `openblas64.pc` for ILP64 builds. Those are standard names, and you can make a choice of whether that's the pthreads or openmp build. For further build flavors there is no standard naming, but you can choose something that makes sense there. It'd be best to provide one .pc file per build though (less important than one LP64 and one ILP64 one, but good practice).

For context: I'm the main maintainer of the NumPy and SciPy build systems. SciPy recently switched from distutils (deprecated) to Meson, and the preferred method for detecting OpenBLAS is pkg-config. If that fails, it will also try via CMake. And I'm in the process of adding a third, custom, method to Meson itself - but either way pkg-config is preferred. NumPy now uses its own custom detection, but is also in the process of switching to Meson.

Let me also point out that there was a bug in the Makefile for OpenBLAS so that it produced `openblas.pc` rather than `openblas64.pc` for ILP64 builds. This is now fixed, see https://github.com/xianyi/OpenBLAS/pull/3791. The OpenBLAS CMake build always did it correctly AFAIK.

> We *could* ship symlinks with flexiblas, but I'm a bit hesitant. This would solve one particular problem, but what if the package decides that ATLAS is the new default? What if they use cmake instead? What if they hardcode the flags? Laugh now, cry later. 

That seems like the right assessment to me.

> $ NPY_BLAS_LIBS="-lflexiblas" NPY_CBLAS_LIBS="" NPY_LAPACK_LIBS="" pip install numpy

I'll note that this will stop working for Python 3.12, when `distutils` is removed from the Python standard library. Numpy will then work just like SciPy (with a command line flag, not env vars).

> Scipy does provide a mechanism [2], but there's currently no way of passing down those parameters through pip [3].

The ability to pass the needed parameter(s) through pip will be added in an upcoming meson-python release, there's a WIP PR at https://github.com/mesonbuild/meson-python/pull/167. The SciPy mechanism will become more flexible, so that it'll also try other BLAS/LAPACK libraries and there'll be a way for users to request the order in which to try them. OpenBLAS will remain the default for the foreseeable future though.

> Exactly because there are multiple flavors and supplying a pkgconfig file gives you the false impression that there's only one variant.

This is simply wrong, no such impression is given. One .pc file per build is quite clear.

> The use of a pkgconfig file is rather limited, since it's easier to just add -lopenblas{,p,o}{,64{,_}} to your link command than patch in the correct pkgconfig file. This is IMHO simpler than having six different pkgconfig files for the different variants, which can silently give you the wrong result. (It's not obvious the default version should be the sequential one.)

This is also wrong; a build system can query pkg-config (that's the whole point), while adding a link flag like that is very ad-hoc and can only work if you already know exactly what you need (which the average end user does not).

Finally, let me point out that *explicitly deleting* a pkg-config file in a build recipe is quite arbitrary, and there's no valid reason for doing so given in this thread. You're making the life of other projects quite difficult by doing such things.

(In reply to Ralf Gommers from comment #23)
> Let's start with what the problem is. There are different personas that may
> want to build from source:
> 1. A Fedora packager, building things in Fedora itself. There's no problem
> there, the answer is: use Flexiblas. 
> 2. End users wanting to build something from source. E.g. for SciPy: `pip
> install scipy --no-binary` (or simply `pip install scipy` on platforms for
> which there are no wheels). There's many other projects who may want
> OpenBLAS though, this issue is not specific to SciPy/NumPy or even Python
> packages (OpenBLAS is the default for R and Julia as well).
> 3. Maintainers/contributors to a package like SciPy, who also have to build
> from source.
> 
> The main difference between (2) and (3) is that for (2) things really should
> work without end user intervention; for (3) that'd be nice, but build
> instructions can contain an extra step. Other than that they're equivalent.
> This "it must work without end user intervention" is important. Not having
> that is a recipe for bug reports and frustrated users. So a "just do this
> symlink step or set this environment variable to make things work on Fedora"
> is bad.

Agreed. (BTW, OpenBLAS is **not** the default for R). Then why the insistence on making the user install a particular BLAS? Why not try OpenBLAS if that's what you prefer, and if this fails, just use cmake's FindBLAS, which would detect **anything** in the user's system flawlessly? (And it also honors input variables that allows you to select a particular version if you know better).

For context: I worked my way through all the packages that consume BLAS/LAPACK in Fedora to implement the change to FlexiBLAS, and I can say with confidence that the ecosystem is a mess. I've seen upstreams reinvent the wheel so many times regarding BLAS detection. FindBLAS just works.

> (BTW, OpenBLAS is **not** the default for R).

Maybe my info is outdated, I don't keep up to date with R. A quick search turned up your article: https://www.r-bloggers.com/2020/10/switch-blas-lapack-without-leaving-your-r-session/. I think that says OpenBLAS with OpenMP is the default, but through Flexiblas.

> Then why the insistence on making the user install a particular BLAS? Why not try OpenBLAS if that's what you prefer, and if this fails, just use cmake's FindBLAS, which would detect **anything** in the user's system flawlessly? (And it also honors input variables that allows you to select a particular version if you know better).

Actually that "try to find anything that works" is what we will do, and what NumPy also does today. OpenBLAS is the default and is what the official binaries (wheels) are shipped with, but we will try to detect as much as possible. I'll note that the Meson migration is not 100% complete (the `distutils` deprecation timeline forced our hand a bit), more flexible BLAS/LAPACK detection is the main WIP item, which is why missing pkg-config files is a lot more painful than it would have been if we had had another 6-12 months. So the insistence is not "must use OpenBLAS" but more "must not delete pkg-config files, because that's bad and we need them right now".

That said, it's still quite useful to know which exact BLAS library you're linking to, rather than linking a shim layer - from introspection for debugging to threading control (no standard APIs for that, see e.g. threadpoolctl). I'll need to investigate what Flexiblas offers there.

On CMake's FindBLAS: it's pretty good, but when I reviewed it last year it was less comprehensive than what `numpy.distutils` has, outside of MKL support. I'm aiming for the Meson support to be a superset of both, and with the ability to use pkg-config, its own builtin detection, and CMake - in that order. By design, pkg-config as a method is certainly superior to going through CMake, and also mixing two build systems (Meson and CMake) is not optimal, so CMake's FindBLAS is a fallback. Stefan (who commented higher up) did try to find OpenBLAS through CMake by the way, which SciPy can already do - but it didn't work.

> For context: I worked my way through all the packages that consume BLAS/LAPACK in Fedora to implement the change to FlexiBLAS, and I can say with confidence that the ecosystem is a mess

Yes, 100% agree it's a mess.

In case you are interested, the info on what the Meson API will look like can be found in:
https://github.com/mesonbuild/meson/pull/10921#issuecomment-1280080059
https://github.com/mesonbuild/meson/issues/2835

Regarding Flexiblas, I'm happy to add that as an option too. From its description it has got interesting properties. There's a number of questions to look into, from licensing (it's GPL-3 with an exception, but we carry BLAS patches for g77 ABI compatibility) to availability across platforms. It hasn't been on my radar yet; a quick search in NumPy shows 4 issues mentioning Flexiblas vs. ~450 OpenBLAS, so that's not surprising.  Let me open a SciPy issue for Flexiblas support later today, I'll Cc you if you don't mind.

(In reply to Ralf Gommers from comment #25)
> > (BTW, OpenBLAS is **not** the default for R).
> 
> Maybe my info is outdated, I don't keep up to date with R. A quick search
> turned up your article:
> https://www.r-bloggers.com/2020/10/switch-blas-lapack-without-leaving-your-r-
> session/. I think that says OpenBLAS with OpenMP is the default, but through
> Flexiblas.

Yeap, I wrote that article. ;-) That's **Fedora's** system-wide default. R itself (upstream) has no preference. In fact, they have an internal implementation based on Netlib for correctness by default.

> > Then why the insistence on making the user install a particular BLAS? Why not try OpenBLAS if that's what you prefer, and if this fails, just use cmake's FindBLAS, which would detect **anything** in the user's system flawlessly? (And it also honors input variables that allows you to select a particular version if you know better).
> 
> Actually that "try to find anything that works" is what we will do, and what
> NumPy also does today. OpenBLAS is the default and is what the official
> binaries (wheels) are shipped with, but we will try to detect as much as
> possible. I'll note that the Meson migration is not 100% complete (the
> `distutils` deprecation timeline forced our hand a bit), more flexible
> BLAS/LAPACK detection is the main WIP item, which is why missing pkg-config
> files is a lot more painful than it would have been if we had had another
> 6-12 months. So the insistence is not "must use OpenBLAS" but more "must not
> delete pkg-config files, because that's bad and we need them right now".

Ok, so I just cloned Scipy locally (with flexiblas-devel installed) and this works for me in your meson.build file:

blas = dependency('openblas', 'BLAS')

Basically, meson tries pkg-config, doesn't work; then tries cmake's find_package, doesn't work; then tries Find modules, and FindBLAS works, FlexiBLAS is detected, compilation proceeds. This is exactly what we were describing: try openblas, if not, give me **any** BLAS through FindBLAS.

> That said, it's still quite useful to know which exact BLAS library you're
> linking to, rather than linking a shim layer - from introspection for
> debugging to threading control (no standard APIs for that, see e.g.
> threadpoolctl). I'll need to investigate what Flexiblas offers there.

This is the greatest advantage of FlexiBLAS: you don't need to know it's there. It just exposes the reference API, and then silently redirects the calls to the optimized versions, if available, according to the configured backend. It just works.

> On CMake's FindBLAS: it's pretty good, but when I reviewed it last year it
> was less comprehensive than what `numpy.distutils` has, outside of MKL
> support. I'm aiming for the Meson support to be a superset of both, and with
> the ability to use pkg-config, its own builtin detection, and CMake - in
> that order. By design, pkg-config as a method is certainly superior to going
> through CMake, and also mixing two build systems (Meson and CMake) is not
> optimal, so CMake's FindBLAS is a fallback. Stefan (who commented higher up)
> did try to find OpenBLAS through CMake by the way, which SciPy can already
> do - but it didn't work.

See above.

> Regarding Flexiblas, I'm happy to add that as an option too. From its
> description it has got interesting properties. There's a number of questions
> to look into, from licensing (it's GPL-3 with an exception, but we carry
> BLAS patches for g77 ABI compatibility) to availability across platforms. It
> hasn't been on my radar yet; a quick search in NumPy shows 4 issues
> mentioning Flexiblas vs. ~450 OpenBLAS, so that's not surprising.  Let me
> open a SciPy issue for Flexiblas support later today, I'll Cc you if you
> don't mind.

Sure.

> This is exactly what we were describing: try openblas, if not, give me **any** BLAS through FindBLAS.

Thanks for testing! We cannot do it exactly like that, because it will lead to segfaults with MKL at least. I explained in more detail on https://github.com/scipy/scipy/issues/17244. We have to deal with many OSes/distros, install methods, compilers, etc. - we really do need to know which BLAS we are getting and handling the special cases. Flexiblas seems great, but we have zero guarantees that it will be installed on an end users machine (outside of Fedora).

I opened a separate issue for adding Flexiblas support to SciPy at https://github.com/scipy/scipy/issues/17362, and Inaki and I are continuing the discussion on whether we can add a generic CMake.FindBLAS usage at https://github.com/scipy/scipy/issues/17244. My expectation is that we will add that support, but it'll take a few months.

That said, let's return to the main topic here. Not shipping OpenBLAS pkg-config files is still a clear bug, and the rationales for not shipping it are a combination of wrong and not given, as I hope I addressed in enough detail above. This is not specific to SciPy/NumPy/Python, the OP just filed a generic "this is missing" bug.

Can you please ship the required .pc files?

The issue was that `pip install scipy` does not work. This is a problem in pip, not Fedora. Fedora has working scipy packages.

The original issue, filed by Pavel, did not mention `pip install scipy`; that was added later by Honza. The question remains whether it is wise to delete the `.pc` file explicitly, and why it is harmful to include, say, one `.pc` file per OpenBLAS variant. Here's the last message by the original filer, asking the same question: https://bugzilla.redhat.com/show_bug.cgi?id=1574517#c6

(In reply to Susi Lehtola from comment #29)
> The issue was that `pip install scipy` does not work. This is a problem in
> pip, not Fedora. Fedora has working scipy packages.

RPMs are not a solution for all (containers in PaaS like OpenShift are one of many examples, where installing RPMs is either much more problematic or not possible because of other complicated reasons). Installing scipy from pip is a totally valid use case.

If users can install something easily to make 'pip install scipy' (and other similar cases where the missing *.pc file makes problems) easily in other distros, why we cannot make it similarly easy for Fedora users? (the easiest solution at this point seems to be creating a symlink by hand)

Anyway, I agree the best solution from the technical perspective might be implementing flexiblas support for scipy, but as mentioned above, it can take long and will not address other projects facing the same issue. Fedora should not close eyes and accept being worse than other distros that easily. And if the solution done in other distros might not be perfect, maintaining the status quo is likely even worse, so maybe accepting non-perfect solution (whatever it is) might actually be better. And if proofed otherwise, the *.pc (whatever it will look like or where it would be) can be removed again.

With all respect to other opinions, I'd like to kindly ask for reconsidering what options we have.

> The issue was that `pip install scipy` does not work. This is a problem in pip, not Fedora. Fedora has working scipy packages.

To me it seems that the issue is that Fedora package explicitly removes openblas.pc, a key component of openblas that other software relies on.
What's the reason to remove this file?