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. > As a practical example, LibreSSL provides source compatibility with > OpenSSL 1.0.1. Its .pc file could include Provides stanzas so that > information could be conveyed. In Fedora today, you have to rely on > the .pc files being named exactly the same so that pkgconfig picks > them up. That introduces file conflicts and other things. That would > not be necessary with pkgconf. You argue that the package being ~14 days old is not a reason not to replace a much older package, still maintained package. I agree, but it's now a reason to replace it either. There need to be some concrete benefits for us to *want* to change. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
