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. > > _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
