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.; > , 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. > [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. > 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. > 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? -- Sounds like unnecessary rash change. Provide an option, that's good and very cool thing! I'll be glad to have a look, too. But there's zero benefit of droping 'pkgconfig' when the rest of non-BSD world considers that to be the standard implementation. Pavel > 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. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
