On Sat, Jan 14, 2017 at 9:29 AM, Pavel Raiskup <praiskup@xxxxxxxxxx> wrote: > On Saturday, January 14, 2017 7:45:05 AM CET Neal Gompa wrote: >> 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 > > 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". 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. [0]: https://fedoraproject.org/wiki/Foundations >> , 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. > > It all sounds really cool, but what makes you think we should drop the old > package, or even switch the default? Simply: I'm all for having pkgconf > in Fedora. > Because pkgconf supports the full specification, including Provides rules. pkgconfig does not. It's been *years* and they never added support for it. It's even documented to be a stub implementation in pkgconfig. As a result of pkgconf fully implementing the Provides rules, .pc files that actually use them will be fully and properly processed and generate pkgconfig() Provides properly. 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. >> [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). > > I haven't been able to install it from my updates-testing mirror, yet. > There's no karma yet. > To be frank, that has nothing to do with me. If your mirrors aren't working, there's nothing I can do. >> 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. > > They are not at least for me, I'll have to install that manually from koji > build. But how this really matters? We are replacing package which is in > Fedora for more than decade with package which is in RPM ~14 days. > We've done things like this before, and we'll likely do it again. This is not a valid argument. >> 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). > > FYI 'git grep PKG_CONFIG' gives me no relevant hit for > autoconf/automake/libtool/gettext git repos. > > Where the PKG_CONFIG stuff is hooked into ./configure is actually m4 file > provided by pkg-config itself (or hardcoding support by particular package > maintainer, or ..). So you claim that you tested only (new) 'pkgconf' > _binary_ against ./configure file generated from (old) 'pkgconfig' > macro file? > Yes, it's part of pkg.m4, which ships in pkgconfig and in pkgconf-m4. pkgconf-m4 is only built when pkgconfig compat subpackage is enabled. The pkg.m4 file shipped in pkgconf (not currently available because of file conflicts) as well as the one in pkgconfig works perfectly fine with pkgconf. The one shipped in pkgconf is actually from pkgconfig anyway. > -- > > Sounds like unnecessary rash change. Provide an option, that's good and very > cool thing! I'll be glad to have a look, too. > The other alternative is using alternatives to switch back and forth (Debian and a few others do it this way). However, I dismissed that plan because pkgconf implements more of the pkg-config file processing specification than pkgconfig does, and it's not reasonable to allow switching back and forth with that kind of inconsistency. We could, of course, just not retire pkgconfig and instead rename the files so they don't conflict. But it would still not be the default implementation in that scenario, either. > But there's zero benefit of droping 'pkgconfig' when the rest of non-BSD > world considers that to be the standard implementation. > That's a horrible argument, considering that Fedora is all about being first to new and better things. I consider pkgconf to be a much better implementation of pkg-config, and it's definitely better maintained than pkgconfig is. The pkgconfig maintainer doesn't mind as long as we're not breaking the ability to build software, and I fully expect that we won't. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
