Hello, Is there some policy for package maintainers and pkg-config? My issue is that a package (libev) used pkg-config for some time, but later dropped it (for legitimate reasons as upstream didn't like that). However, should we really care about upstream in cases like that?
I was making a package that depended on libev and was using: "pkg-config --cflags libev" to obtain the CFLAGS in order to compile (libev is installed in a non-standard path in Fedora). Now in rawhide that libev doesn't install the pkg-config file, I have to hard code -I/usr/include/libev in my spec.
Apart from the annoyance from having to change my spec file for such a change, I find the latter sub-optimal. Now my package hard-codes another package's installation path (that may theoretically change at any point). Wouldn't in that case, where non-standard paths are being used, be better to have the pkg-config file in fedora, even if upstream doesn't adopt it?
regards, Nikos
2014-03-19 11:30 GMT+01:00 Nikos Mavrogiannopoulos nmav@redhat.com:
Hello, Is there some policy for package maintainers and pkg-config? My issue is that a package (libev) used pkg-config for some time, but later dropped it (for legitimate reasons as upstream didn't like that). However, should we really care about upstream in cases like that?
Very broadly, this isn't too different from upstream making any other API-breaking change. We sometimes complain to them, sometimes help them stop doing that in the future, but typically we don't diverge from upstream to revert an API break. Specific circumstances can of course be different.
Apart from the annoyance from having to change my spec file for such a
change, I find the latter sub-optimal. Now my package hard-codes another package's installation path (that may theoretically change at any point). Wouldn't in that case, where non-standard paths are being used, be better to have the pkg-config file in fedora, even if upstream doesn't adopt it?
We do have some precedents in this area (openssl adding a pkg-config file to record flags necessary for our Kerberos-enabled build, adding a pkg-config file to avoid a multi-lib conflict in /usr/bin/$library-config), but those I can think about are motivated by needing to solve a specific problem. We don't have a general policy to require all libraries to provide a pkg-config file, or anything similarly broad AFAIK. Mirek