On Sat, Jan 14, 2017 at 2:35 PM, Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > On Sat, Jan 14, 2017 at 10:45:48AM -0500, Neal Gompa wrote: >> On Sat, Jan 14, 2017 at 10:30 AM, Adam Williamson >> <adamwill@xxxxxxxxxxxxxxxxx> wrote: >> > On Sat, 2017-01-14 at 09:51 -0500, Neal Gompa wrote: >> >> 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. >> > >> > But...you just said yourself it's not "fully compatible": >> > >> >> I should be more clear... It's fully compatible with pkg-config (the >> specification) and supports many of the quirks that several pkg-config >> implementations have (including pkgconfig), but it isn't bug-for-bug >> matching behavior with pkgconfig. The way it handles dependency >> resolution is different, and how it merges fragments differs too. >> >> The differences are described pretty well on http://pkgconf.org/features.html >> >> > "Admittedly, it is less >> > tolerant of badly written .pc files, but those should be fixed, >> > anyway." >> > >> > To me, 'fully compatible' means 'we can switch tomorrow and nothing >> > will stop building'. It doesn't mean 'compatible with the letter of the >> > specification'. >> >> I expect it will be a "we can switch tomorrow and nothing will stop >> building" scenario. In terms of behaviors between pkgconf and >> pkg-config, the big difference is that Provides stanzas and >> Cflags.private stanzas are processed properly in pkgconf, whereas they >> are ignored in pkgconfig. In the case of the Provides stanzas, we're >> requesting that information for RPM dependency generators, but in >> pkgconfig, all it does is return the name of the .pc file without the >> file extension and adds the version to it. > > Hi, > > the apparent opposition to this change might come from the relative sparsity > of the "Benefit to Fedora" and "Upgrade/compatibility impact". > > In the "Benefit to Fedora" section, it would be nice to have a longer > description: what is the significance of "Provides rules and > Cflags.private rules being supported"? What are the speed changes? > > In the mailing list thread use of the library api was mentioned, and > connection to Meson/CMake/something-else. This is not mentioned in the > wiki page at all. > > You argue that the change should be mostly painless, but without > providing any details: why not rebuild a 10 or 100 or 1000 packages > in a mock root with pkgconf-pkg-config? Even if there are some minor > hiccups, at least we'll be able to estimate the effort for the whole > archive in the "Upgrade impact" section. > I had done some tests locally before, but a DNF bug[1] made it so it didn't work in COPR, as the host DNF is 1.1.x and afflicted with the issue (I use DNF 2.0 locally). I worked around it (see dummy empty pkgconfig package that just pulls in pkgconf-pkg-config) so that I could publish some test builds through COPR[2]. I've gone through a few packages that explicitly BuildRequire pkgconfig (using "dnf repoquery --source --whatrequires 'pkgconfig'" to identify them) as well as one or two that I just felt like throwing into the mix. I'll probably keep throwing more random things into there, but you can see that so far, they've all been successful, using pkgconf as the pkg-config implementation, with no loss in generated data in terms of pkgconfig() Provides and Requires, and no build systems have fallen over when using pkgconf. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1332830 [2]: https://copr.fedorainfracloud.org/coprs/ngompa/f26-pkgconf/builds/ -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
