On Sat, Jan 14, 2017 at 10:58 AM, Pavel Raiskup <praiskup@xxxxxxxxxx> wrote: > Hi Neal! > > On Saturday, January 14, 2017 9:51:39 AM CET Neal Gompa wrote: >> > I hope no. Can you be precise here? I'm all for protecting Fedora's >> > interests.; >> >> I strongly believe in Fedora's Foundations[0], which include a commitment to >> "excellence" and "innovation". > > I hope it all is about excellence and innovation; and not about personal > preference. Personally, I just would let the projects themselves prove > which of them performs better (for example, I am glad I can help Fedora > with maintenance of 3 'tar' implementations now). I think Gentoo for > example has both implementations. > Gentoo and Debian have both pkgconfig and pkgconf, so it's not unheard of. >> And being afraid of switching to a different and fully compatible >> implementation of pkg-config just because it's not the implementation >> we've used for over a decade is contrary to those values. > > I'm not really afraid of something now, just trying to be fair. > > FWIW, why it is _not a fork_, but rather complete rewrite? Yes, rewriting > software is fun, and WRT BSD I see a "licence issue" to be the reason for > rewrites. > It was mentioned earlier in the thread that pkgconf was not originally planned to provide a frontend interface (it was intended to be a library). But when pkgconfig introduced the glib2 dependency, making it difficult to build and bootstrap, pkgconf grew a CLI program to act as a replacement. Yes, it's licensed ISC, which is more palatable for BSDs, but everyone was mostly okay with pkgconfig until the glib2 dependency was introduced (and not even for a good reason, like offering a library with g-i support). After that happened, lots of independent implementations showed up (OpenBSD's implementation in Perl, which lacks Conflicts support, Perl and Python implementations as modules implementing subsets for archful builds, etc.). pkgconf intends to offer a uniform interface for all types of applications that leverage the pkg-config specification. >> Because pkgconf supports the full specification, including Provides >> rules. pkgconfig does not. It's been *years* and they never added >> support for it. > > That sounds like valid argument, just to be sure .. have authors of > pkgconf tried to submit patches against pkgconfig first? > I don't think so. The Provides rules support was added because I asked for it, because there were cases where it makes complete sense to have them. The Cflags.Requires feature was a feature request to pkgconfig 3 years ago[1] that went nowhere and led to the project in question requesting it to switch to pkgconf. There are plenty of long-living bugs that haven't been addressed in a while in pkgconfig[2]. [1]: https://bugzilla.freedesktop.org/show_bug.cgi?id=47996 [2]: https://bugzilla.freedesktop.org/buglist.cgi?component=src&product=pkg-config&resolution=--- >> pkgconf also does unit testing and continuous integration testing. I >> run the unit tests on every package build, and upstream does continuous >> integration on various systems offering or using pkgconf. > > Cool. Let's provide 'pkgconf' so we can be also three, too! But at the > same time please consider not dropping 'pkgconfig' for no reason. > We could certainly retain both implementations, but it we would need to decide on an approach on how to keep both. Two ways to do it: 1. Use alternatives. This is how Debian does it. I think this is probably a bad idea because it's very possible to get inconsistent results due to the differences of the two resolvers, depending on how someone builds locally. The missing features in pkgconfig could lead to a bad experience, too. 2. Rename the conflicting files in pkgconfig. I'd prefer this approach, as then people can explicitly use it though the mechanisms I've mentioned earlier in the thread. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
