This is a DNF bug, transferring to them.

Just to expand a bit—there might be other effects, but the ultimate problem that this causes for wine is that attempts to do a 32-bit pkg-config fails. E.g. if one installs x86_64 and then i686 freetype-devel as described above, 

$ i686-redhat-linux-gnu-pkg-config --cflags freetype2

results in error messages (because e.g. harfbuzz-devel.i686 isn't installed).

(It's worth mentioning that we don't use i686-redhat-linux-gnu-pkg-config directly, but rather manually set PKG_CONFIG_LIBDIR. We would, but the fact that it's using a nonstandard name makes things a bit annoying. Arguably at least checking for multiple pkg-config names would be an improvement over setting PKG_CONFIG_LIBDIR, though.)

[pmatilai🎩︎localhost ~]$ repoquery --requires freetype-devel.x86_64
Last metadata expiration check: 0:00:08 ago on Fri 25 Nov 2022 08:15:08 AM EET.
/usr/bin/pkg-config
/usr/bin/sh
freetype = 2.12.1-3.fc37
libfreetype.so.6()(64bit)
pkgconf(x86-64)
pkgconfig(bzip2)
pkgconfig(harfbuzz) >= 2.0.0
pkgconfig(libbrotlidec)
pkgconfig(libpng)
pkgconfig(zlib)
[pmatilai🎩︎localhost ~]$ repoquery --requires freetype-devel.i686
Last metadata expiration check: 0:00:13 ago on Fri 25 Nov 2022 08:15:08 AM EET.
/usr/bin/pkg-config
/usr/bin/sh
freetype = 2.12.1-3.fc37
libfreetype.so.6
pkgconf(x86-32)
pkgconfig(bzip2)
pkgconfig(harfbuzz) >= 2.0.0
pkgconfig(libbrotlidec)
pkgconfig(libpng)
pkgconfig(zlib)

There's nothing in there to indicate that harfbuzz(-devel) should be of a specific architecture. Since dependencies are satisfied, it's hard to call it a dnf bug. This is more a flaw in the pkgconfig dependencies which lack the necessary 32/64bit info.

According to the Panu's answer it seems like an issue related to the packaging of this specific product. I am trying to delegate this to freetype guys and see what is their input on this.

Actually, I think this is related the pkgconfig generator, which is part of rpm...

It's part of rpm, but changing how pkgconfig dependencies are created would be a huge undertaking, ie not something we can just go and fix and afterwards everything will be okay.

Oh and actually, Fedora packaging guidelines effectively prohibit us from doing anything about it:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_buildrequires_and_isa
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_buildrequires_based_on_pkg_config

Ie, pkgconfig() dependencies are recommended for BuildRequires, but at the same time BuildRequires MUST NOT be arch/isa-specific which is what they'd need to be in order to make this work with pkgconfig() deps.

https://docs.fedoraproject.org/en-US/packaging-guidelines/#_architecture_specific_dependencies outlines how it can be fixed on per-package level though: add a manual arch-specific dependency to the -devel package. In this case, in freetype-devel,

    Requires: harfbuzz-devel%{_isa} 

...but good luck getting every -devel dependency in the distro fixed like that. I'll reassign to freetype though as that's the one place where this particular issue *can* be dealt with right now.

thanks for looking into it

actually, in wine, we've had report for failure with gstreamer-devel package as well, but we can't be 100% sure that the only two ones (with freetype) which will generate issues regarding dependencies

so before going for a one package only change, we perhaps have to choose between:
- fix all -devel deps in Fedora, so Fedora will behave as others distros do (at least the debian based ones <g>)
- fix all -devel deps for the broken report we have in Wine; likely one by one
- workaround it in Wine, by falling back to the 64bit .pc if no 32bit can be found (or something similar) (that what we were doing before a config change that opened this ticket)

Well, the way it works for Debian is that there's an architecture preference when requesting unarched dependencies. I don't think we have something similar in DNF's solver logic, but maybe @mls knows if it's possible with libsolv?

This message is a reminder that Fedora Linux 37 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05.
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
'version' of '37'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 37 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 Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Fedora Linux 37 entered end-of-life (EOL) status on None.

Fedora Linux 37 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 Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

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

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days