The way dynamic arch.works with the official package is that they all get built, and the specific architecture will get selected at runtime for a slight penalty cost at startup. The package install is thus much bigger and loading time is slower. The community package is not "superior in every aspect", it makes different choices under different constraints. Same for the TLS use flag. This package has been updated regularly. I've submitted multiple changes upstream from the feedback of users using this package while the community package didn't exist. I think this package serves its purpose. I don't understand why you want to have it deleted, while this doesn't break anything as far as I know? Nobody forces you to use this package, feel free to use the official one.

On Mon, Jul 3, 2023 at 1:42 PM Marcell Mészáros <meszaros.marcell@runbox.com> wrote:
Dynamic architecture support means one binary can take advantage of a wide range of microarchitectures.

Also, your build turns on USE_TLS, a "new, still somewhat experimental code that uses thread-local storage instead of a central memory buffer".

Which is exactly what it should not do in a production-targeted build.

You should create a new package with a descriptive name suffix, like '-experimental-tls' or something.


On 3 July 2023 19:33:04 GMT+02:00, Marcell Meszaros <marcell.meszaros@runbox.eu> wrote:
Arch repo openblas is already built with multiple microarchitecture support through
  cmake '-DDYNAMIC_ARCH=ON'.

https://gitlab.archlinux.org/archlinux/packaging/packages/openblas/

Your PKGBUILD, however, does not seem to enable the same for its build with make.

The latter also does not build 64-bit precision libraries, whereas the repo buildscript does.

So as of now, the new repo package is superior to this original AUR one, in every aspect that you mentioned.


On 3 July 2023 19:11:20 GMT+02:00, Guillaume Horel <guillaume.horel@gmail.com> wrote:
Openblas is a performance oriented package, microarchitecture optimization is exactly what it's about. Moreover this PKGBUILD has different build options than the official one which is allowed by the guidelines.

On Mon, Jul 3, 2023 at 11:32 AM Marcell Meszaros <marcell.meszaros@runbox.eu> wrote:
> The package in community provides the dynamic arch version, whereas this one will be specifically tuned for your current architecture.

But this is not a good enough reason to keep PKGBUILDs for the same source in both Arch repo and on AUR.

Arch is not a binary-only distribution: all the build scripts are availabe.

One can always grab a couple of PKGBUILDs from Arch repo's GitLab for fine-tuned, microarchitecture-optimized rebuild, if that is what they want.

But AUR submission guidelines are quite clear: they don't mention allowing duplication for this purpose.


On 2 July 2023 17:34:03 GMT+02:00, Guillaume Horel <guillaume.horel@gmail.com> wrote:
This is not the exactly the same package. The package in community provides the dynamic arch version, whereas this one will be specifically tuned for your current architecture.
I've responded in the comments that there is nothing broken at the moment with this package, and I don't see the need to delete it.

On Sun, Jul 2, 2023 at 7:17 AM <notify@aur.archlinux.org> wrote:
MarsSeed [1] filed a deletion request for openblas-lapack [2]:

Same package is now in [extra], named blas-openblas:

https://archlinux.org/packages/extra/x86_64/blas-openblas/

See announcement about it:
https://archlinux.org/news/openblas-0323-2-update-requires-manual-
intervention/

I have notified AUR maintainers in comments about their need to review
this change, and possibly adapt their PKGBUILD's.

[1] https://aur.archlinux.org/account/MarsSeed/
[2] https://aur.archlinux.org/pkgbase/openblas-lapack/