Hi Neal!
On Saturday, January 14, 2017 9:51:39 AM CET Neal Gompa wrote:
> 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".
I hope it all is about excellence and innovation; and not about personal
preference. Personally, I just would let the projects themselves prove
which of them performs better (for example, I am glad I can help Fedora
with maintenance of 3 'tar' implementations now). I think Gentoo for
example has both implementations.
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.
I'm not really afraid of something now, just trying to be fair.
FWIW, why it is _not a fork_, but rather complete rewrite? Yes, rewriting
software is fun, and WRT BSD I see a "licence issue" to be the reason for
rewrites.
Because pkgconf supports the full specification, including Provides
rules. pkgconfig does not. It's been *years* and they never added
support for it.
That sounds like valid argument, just to be sure .. have authors of
pkgconf tried to submit patches against pkgconfig first?
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.
Cool. Let's provide 'pkgconf' so we can be also three, too! But at the
same time please consider not dropping 'pkgconfig' for no reason.
> 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.
OK. Enjoy your weekend, Neal.
Pavel
>> 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.