> is needed to build anything based on libxi

"build anything" implies makedep. There is no runtime dep on libfixes. There is nothing in the packaging guidelines justifying this so could you please reassess?

This is the same as  FS#76959 

And we have other packages in the repository, which are not linked to libxfixes, but specified in their *.pc file:
- libxcomposite
- libxdamage
- libxpresent

So if you say it should be a makedep, then it should be removed from these three packages. But I don't think it would be good. And we have xorgproto dependency of libx11 for the same reason. xorgproto is a build time dependency of anything which depend on X11 libraries.

Maybe we could mention in the guidelines that dependencies from *.pc files might be declared as dependencies.

This is the output of pkg-config if libxfixes is not installed:

$ pkg-config --cflags xi
Package xfixes was not found in the pkg-config search path.
Perhaps you should add the directory containing `xfixes.pc'
to the PKG_CONFIG_PATH environment variable
Package 'xfixes', required by 'xi', not found

The dependency is only used in static linking which is not possible with libxi as it does not ship a static library. So if it is removed from the .pc then it does not need to be added to package dependencies.

@loqs: Yes, if we remove the 'Requires.private' fields from the .pc files of libxi, libxcomposite and libxpresent packages, then we don't need to add libxfixes dependency for them. It could be a good solution.

Bottom line (though of course there are exceptions):

- depends -> "run time"
- makedepends -> "build time"

.pc files and header files only matter at "build time" (with a few exceptions). I believe you are overthinking things and therefore creating confusion. Can we please just keep things simple? Probably too much staring at namcap code :)

I think if a .pc file is present, then it's expected that all of its dependencies are present. Since we don't split header files into separated '-dev' package, it's expected to build someting on it will be successful without these kind of errors. But the main problem is that pkgconf checks the existence everything declared in 'Requires.private', even if we don't do static builds. So we have to do something with that... And namcap is the best! :)

Maybe bring this to the ML to find some agreement for how to deal this for all use cases in a common way or leave it up to the maintainers and maybe how to check using namcap in the future to throw some warning.

I prefer a pragmatic way to only add header packages to the depends when a large group of packages would need to add it to the makedepends otherwise like we do with xorgproto.

I implemented a new rule for this in namcap:
https://gitlab.archlinux.org/pacman/namcap/-/merge_requests/28

And I posted about it on arch-dev-public mailing list:
https://lists.archlinux.org/archives/list/arch-dev-public%40lists.archlinux.org/thread/A2MV7T3NDHVHWX6WHIHH2DKH4YSWSIIX/

The new namcap rule can be tested with my namcap-improved package from AUR:
https://aur.archlinux.org/packages/namcap-improved

Maybe it's just me, but I still fail to see what *.pc files have to do with "run time". Sure, having correct *.pc files is an admirable goal, so I have no objections...as long we are *not* adding obviously unnecessary "run time" depends just to satisfy some problematic "build" tool i.e. pkg-config. To reiterate, *running* a program is one thing, but *building* a pkg is a completely separate exercise.

After all, "Keep It Simple" is literally in the first sentence on the Arch front page and is a foundation principle. Please let's not over-complicate things and become another Debian.

But I do agree with your point in the mailing list posting about systemd and pkg-config and have whinged about it in the past [1].

[1] https://bugs.archlinux.org/task/75194#comment209572