Re: Box2D: providing .pc files even if upstream does not?
2014-03-01 16:16 GMT+01:00 Bas Wijnen <wijnen@debian.org>:
>
> > Should we continue to ship a .pc file and diverge from upstream here
> > or drop pkg-config support to avoid angry bug reports like
> >
> > https://bugs.debian.org/715796
> >
> > for the tinyxml package?
>
> Avoiding angry bug reports may be good for keeping your sanity, but in
> general I don't think we should allow such extortion to be our guide.
>
> Regardless of the tone, he does have a point, though. If upstream
> doesn't accept our patch (of course we will send it upstream), then the
> main purpose of providing the file, platform independence, is lost.
>
> On the other hand, that is not the only purpose. The other purpose is
> that pkgconfig provides a uniform interface for all libraries on the
> system. That is useful even if other platforms don't do it. For this
> reason, I'm mildly in favor of providing the file even if upstream
> doesn't. Strongly if the library requires weird build flags that nobody
> can remember.
As the person who added the .pc file to our package, I strongly
support having it in there even if upstream doesn't support it. I
think it provides enough benefits for those of us who prefer using
pkg-config in our building systems, and it doesn't have any drawbacks:
if you don't want to use it, you can safely ignore it.
Having said that, I don't feel like having any other flame about
anything for a while, so if there's a consensus that we shouldn't add
these kind of features to what upstream wants to ship (this also
include, in some cases, and very carefully, building dynamic libraries
when upstreams are not doing it), or if there is no consensus about
it, but the person who is effectively taking care of the package at a
moment decides to do so, I won't put up a fight about it. In any case,
when all is said and done, I can always add my own .pc files locally
in my projects if I prefer it that way.
Greetings,
Miry
Reply to: