Please use Semantic Line Breaks as described in the README.
In absence of better tooling, that makes review much easier.
Also in the future, diffs will be much nicer when something is changed.

Done.

How do I deal with the 32/64bit thingy if I don't like the pkgconfig() way of buildrequires? Or do I have to use them? It seems that both pkgconfig(flexiblas64) and pkgconfig(flexiblas) are provided by flexiblas-devel on 64bit platforms, so i suppose the thing is not required when I just use flexiblas-devel? It is a bit hard to understand as a whole, maybe the section could be restructured a bit? E.g.:

Package uses 32/64 bit stuff where available

do this

Package uses only 32 bit

do that

Package uses only 64 bit

do the arch exclude and that

?

Other than that, I think this is good and explains everything. Might be noted that the Backend selection section is not that relevant to the packager, but it adds more context, so I'd keep it.

Thanks for the feedback!

How do I deal with the 32/64bit thingy if I don't like the pkgconfig() way of buildrequires? Or do I have to use them? It seems that both pkgconfig(flexiblas64) and pkgconfig(flexiblas) are provided by flexiblas-devel on 64bit platforms, so i suppose the thing is not required when I just use flexiblas-devel? It is a bit hard to understand as a whole, maybe the section could be restructured a bit?

I see. I added the pkgconfig part to avoid clashing with the pkgconfig directive already in the guidelines, but yes, everything is packaged in flexiblas-devel and both directives bring in the same stuff. So if an exception can be made, I would prefer to simplify that subsection and just recommend BuildRequires: flexiblas-devel. Then, add more details about the specific commands to find the proper flags with pkg-config in both cases.

Other than that, I think this is good and explains everything.

Thanks! :)

Might be noted that the Backend selection section is not that relevant to the packager, but it adds more context, so I'd keep it.

Yes, I agree, and that's also why I put it at the end. ;)

This is what I was talking about. Added as a new commit for your convenience (and mine if we want to revert). We can rebase later if you wish.

Awesome.

+1 for merging

Looks great to me!

+1

+1

The only question that comes to mind is whether we need to link to these from the main guidelines in some way or if just listing them in the sidebar is sufficient.

I added a link to the index too. Not sure if this is what you mean.

Repeated word: operations operations

Thanks for spotting this, fixed now.

+1