<div dir="ltr">2014-03-19 11:30 GMT+01:00 Nikos Mavrogiannopoulos <span dir="ltr"><<a href="mailto:nmav@redhat.com" target="_blank">nmav@redhat.com</a>></span>:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello,<br>
Is there some policy for package maintainers and pkg-config? My issue<br>
is that a package (libev) used pkg-config for some time, but later<br>
dropped it (for legitimate reasons as upstream didn't like that).<br>
However, should we really care about upstream in cases like that?<br></blockquote><div><br></div><div>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. </div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Apart from the annoyance from having to change my spec file for such a<br>
change, I find the latter sub-optimal. Now my package hard-codes another<br>
package's installation path (that may theoretically change at any<br>
point). Wouldn't in that case, where non-standard paths are being used,<br>
be better to have the pkg-config file in fedora, even if upstream<br>
doesn't adopt it?<br></blockquote><div><br></div><div>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.</div>
<div> Mirek</div></div></div></div>