Re: Diagreement with pkgconfig removal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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, 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.

[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). 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. 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). 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.

-- 
真実はいつも一つ!/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux