On Sat, Jan 14, 2017 at 7:10 AM, Pavel Raiskup <praiskup@xxxxxxxxxx> wrote: > On Friday, January 13, 2017 1:18:34 PM CET Neal Gompa wrote: >> On Fri, Jan 13, 2017 at 12:20 PM, Pavel Raiskup <praiskup@xxxxxxxxxx> wrote: >> > On Friday, January 13, 2017 5:54:41 PM CET Pavel Raiskup wrote: >> >> Doh I missed this. This is now approved due to "bootstrapping issue". So the >> >> way to use "old" pkgconfig is (in case of FTBFS)? >> > >> > Reading again the proposal, there's compatibility layer -- but the old >> > implementation nowhere (Obsoleted)? >> > >> > The package is in Rawhide ~2weeks. What set of packages has been rebuilt to >> > test for peculiarities? Who else (distros) did this change and why? >> > >> > Who pinged upstream of "old" pkgconfig (seems like the last release is from >> > 2016, it is not dead). >> > >> > Why don't we have both implementations and let user's pick the >> > implementation they like? And resolve the "bootstrapping issue" with the >> > implementation which better suits ...? >> > >> >> The pkgconf-pkg-config package has not been enabled yet. Once this >> change is accepted, I'll build to enable it, and the distribution will >> automatically prefer it over pkgconfig (since pkgconf-pkg-config >> provides a slightly higher version of pkgconfig and Conflicts with >> pkgconfig versions lower than what it provides for this purpose). >> After mass rebuild completes, pkgconfig can be retired from >> Rawhide/F26 and pkgconf-pkg-config can Obsolete it. > > Sorry this doesn'ŧ answer my clear questions, still OK to answer them.. > > It looks like somebody needs to test some re-implementation of pkg-congfig (and > I'm pretty sure Fedora Rawhide is not correct place to play such games). I'm > curious how it is even possible that we in Fedora are able to do such quick > decissions. > You and I have different views on what Fedora is about, clearly. And this is absolutely no game. That being said, pkgconf has been brutally tested by FreeBSD Ports and pkgsrc (BSD and Linux), where it has survived multiple mass rebuilds. GNOME already makes incompatibilities with pkgconf a blocker in their release strategy, and while pkgconf is fully conformant to the "specification" of .pc files, it already supports more of it than pkgconfig does. Admittedly, it is less tolerant of badly written .pc files, but those should be fixed, anyway. I am extremely confident that the change will be mostly (if not completely) transparent. The other big advantage of pkgconf is the library. libpkgconf provides a more natural interface to integrate pkgconfig processing into applications, and there are Python bindings[1] being developed. A third party has already developed Perl bindings[2], as well. Tools like CMake, Meson, and SCons can leverage libpkgconf to provide better processing for dependencies. One of the developers of Meson is already working on using pkgconf-py for Meson as the preferred pkg-config engine. [1]: https://github.com/pkgconf/pkgconf-py [2]: https://github.com/plicease/PkgConfig-LibPkgConf > The package *is not yet available to test* in Fedora 25 updates-testing, > and now we agreed it should replace 17 years old and _still alive_ > package? > It's been available in Fedora 24 and Fedora 25 updates testing for the last two weeks in some form. I have not pushed it to stable because I have been fixing things and editing the initial update (it's a newpackage update, anyway). Fedora 24 and Fedora 25 are *not* getting the pkgconf-pkg-config subpackage enabled, ever. > Please provide the new pkgconf package as 1:1 replacement for pkg-config (being > concurrently installable) so users have an option to use it for whatever reason, > abut *don't* drop the old implementation for no good reason. Then we are able > to do benchmark and confirm that what the pkgconf's marketing claims is really > truth and we can switch the defaults. Both implementations are already concurrently available. Without the pkg-config subpackage, you can switch to pkgconf *now* for your builds by installing "pkgconf" and setting "PKG_CONFIG" to "/usr/bin/pkgconf" in your environment. Most build systems respect the variable (at least Autotools and CMake do, from my testing). The symlink pointer (provided by pkgconf-pkg-config) is necessary for things that hardcode /usr/bin/pkg-config to use pkgconf, as the CLI accepts the same args as pkgconfig and prints the same kind of output. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
