Open copumpkin opened 8 years ago
This particular case: Libs.private
are supposed to be only relevant during static linking, IIRC. We typically don't do that. In general it would certainly be nice, but unfortunately there are many similar wish-list items that seem like noone has time to pick up...
Another example could be "nativeBuildInputs
should always be disallowed requisites".
Some packages that provide a C plugin API often capture things like exact compiler command lines, paths to tools like pkg-config. It's fine to have that in .dev
outputs.
Thank you for your contributions.
This has been automatically marked as stale because it has had no activity for 180 days.
If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.
Here are suggestions that might help resolve this more quickly:
Many packages contain
pkg-config
spec files that can reference external libraries, and anything that appears inLibs.private
in there should probably be in the package'spropagatedBuildInputs
. That seems like something we could check at build time to avoid future pain.Similarly, many packages provide headers that themselves include headers from their dependencies. Those dependencies should also probably show up in
propagatedBuildInputs
.There are probably other examples of this within the individual language ecosystems.