Solved - How to account for dependencies of dependencies of dependencies, etc. when writing a package?

Here’s another question about this Workrave-git gist that I wrote:

I basically started with the dependencies of the original Workrave package, replaced the autotools dependencies with cmake (because the newer Workrave uses cmake), and then as pkg-config complained that some dependency of a dependency was missing, or some dependency of a dependency of a dependency was missing, or some dependency of a dependency of a dependency of a dependency was missing, I kept adding that dependency until pkg-config stopped complaining.

The problem with this is that as dependencies accrued, I kept seeing more and more distantly related dependencies, like util-linux, libselinux, libthai, etc., which might be dependencies in some platforms but not others, which seems fragile. I thought that this was odd, but until I read about propagatedBuildInputs in Nix pills, I thought it might be unavoidable.

Is there a proper way of handling these dependencies? Should they have been part of the dependent packages propagated build inputs (and thus something to write a bug report about)? Should I have ignored the warnings from pkg-config until I got a compilation error? How should this have been be handled?

ETA: Looks like I got tricked by the problem described here: `awesome` is missing inputs · Issue #284596 · NixOS/nixpkgs · GitHub

To quote the linked comment from @jtojnar: “That is an issue of CMake incorrectly reporting pkg-config dependencies. It can be safely ignored.”