Hello, On Sat, Jan 14, 2017 at 9:58 AM, Pavel Raiskup <praiskup@xxxxxxxxxx> wrote: > 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. One should probably point out that tar is not a critical toolchain component while the system pkg-config implementation is. :) >> 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. So, some background here: the software that became pkgconf originally came out of the desire to provide awareness of pkg-config files to, amongst other things, the Alpine Linux build environment and package system. When pkg-config 0.26 came out and gained the glib2 dependency, requiring special steps to bootstrap, we decided it was relevant to change the focus of the project to also provide a pkg-config frontend so that we did not have to deal with bootstrapping yet another circular dependency. As for the ISC license; there was interest from the FreeBSD guys in doing the same work, so we decided to work together with them -- as such a non-copyleft free software license was the most palatable option to everyone involved, so we went with that. At no point was this really a "lets rewrite pkg-config as BSD license for the fun of it" affair, it was done because pkg-config was now a circular dependency and we didn't want to deal with it, as we already had a lot of the pieces we needed to make a replacement frontend. >> 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? So, "specification" isn't the right word here in my opinion -- at least it is one I try to avoid using when speaking of .pc files, as there is no formal specification, but I have to give the Gentoo guys props for trying to start the conversation. What he means is: pkg-config has a lot of features that are incomplete. For example --print-provides is a stub in pkg-config that was never realized for anything beyond printing some output for RPM's dependency generator. But one has to question why the RPM developers wanted --print-provides in the first place -- obviously they wanted pkg-config to be able to mirror the Provides functionality of RPM, otherwise why not just extract the data from the pkg-config file using --modversion in RPM's dependency generator? Another example is CFLAGS.private, which allows for defining CFLAGS specific to static builds. This is mainly for things like -DFOO_STATIC which can be used for disabling code that shouldn't be used in a static build (or on Windows various dllimport/dllexport stuff). Beyond that: pkgconf actually behaves more in a way that people expect. The output of the frontend in cases where it differs from pkg-config's output is usually more correct and expected than the output of pkg-config, there have been many build engineers that have "solved" their problems with pkg-config by using pkgconf instead. It is also a policy for pkgconf that any feature that is requested and accepted by us is actually properly implemented: for example, pkgconf (when built against Cygwin or MSYS) is fully aware of the Cygwin/MSYS environment and can relocate paths using cygwin_conv_path(). pkg-config on the other hand only has the prefix relocation feature, which isn't always the right thing, so downstreams have to patch it. >> 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. The reason is that developers would like to make use of the features properly implemented in pkgconf that are missing or incomplete in pkg-config. A good example would be allowing libressl.pc to provide openssl.pc. >> > 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
