F26 System Wide Change: pkgconf as system pkg-config implementation

[Jan Kurik]

= System Wide Change: pkgconf as system pkg-config implementation =
https://fedoraproject.org/wiki/Changes/pkgconf_as_system_pkg-config_imple...

Change owner(s):
* Igor Gnatenko <ignatenkobrain AT fedoraproject DOT org>
* Neal Gompa <ngompa13 AT gmail DOT com>

This change switches Fedora's system-wide/default pkg-config
implementation to pkgconf, a new implementation of pkg-config that
provides better support for handling .pc files and a stable library
ABI/API for integrating into applications.


== Detailed Description ==
pkgconf is a newer, actively maintained implementation of pkg-config
that supports more aspects of the pkg-config file specification and
provides a library interface that applications can use to incorporate
intelligent handling of pkg-config files into themselves (such as
build file generators, IDEs, and compilers). Through its pkg-config
compatibility interface (activated when it is run as "pkg-config"), it
also can completely replace the original implementation. This change
involves enabling the pkgconf-pkg-config subpackage that provides this
compatibility interface in Rawhide, and having it obsolete+provide the
pkgconfig package so that it is the system implementation of
pkg-config for the distribution.


== Scope ==
* Proposal owners:
1. Enable pkgconfig compatibility layer in pkgconf package (which is
in conflict with pkgconfig)
2. Ensure that it doesn't break major number of builds during mass-rebuild
3. Fix issues

* Other developers:
Retire pkgconfig package (Matthias Clasen) if everything went well
right after mass-rebuild and fixage of all broken packages due to this
change

* Release engineering:
Mass rebuild is needed (to ensure that pkgconf implementation is
used), owners of change will track mass-rebuild and fix issues
appearing with new implementation

* List of deliverables: All

* Policies and guidelines:
Nothing needs to be updated, (Build)Requires will still work as
expected in pkgconfig() form, paths are not changing

*Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

[Owen Taylor]

On Wed, 2017-01-04 at 09:20 +0100, Jan Kurik wrote:
>  = System Wide Change: pkgconf as system pkg-config implementation =
>  https://fedoraproject.org/wiki/Changes/pkgconf_as_system_pkg-config_i
>  mplementation
>  
>  Change owner(s):
>  * Igor Gnatenko <ignatenkobrain AT fedoraproject DOT org>
>  * Neal Gompa <ngompa13 AT gmail DOT com>
>  
>  This change switches Fedora's system-wide/default pkg-config
>  implementation to pkgconf, a new implementation of pkg-config that
>  provides better support for handling .pc files and a stable library
>  ABI/API for integrating into applications. 
I think it would be really helpful to know a bit more background - who
are the people developing pkgconf, how did the project start? Has there
been discussion with the current pkg-config maintainers about what they
think of this project and whether they would want to retire pkg-config
in favor of this project?

And why is an incompatible 'pkgconf' command line needed in addition to
the pkg-config wrapper? If the pkgconf project was the official version
of pkg-config and they could evolve the 'pkg-config' command line would
that be sufficient? Having two commands sounds like it will make
documentation about anything related to .pc files much more confusing.
(And pkg-config vs. /usr/lib/pkgconfig was already confusing...)

I don't see a problem with pkg-config being rewritten, but I do see a
problem if there's a fork without a clear direction that is likely to
be followed by all distributions. There has to be a single definition
of what goes in a .pc file and what the interface is, and what happens
when you run pkg-config, or use PKG_CHECK_MODULES in a configure.ac
file.

- Owen

[William Pitcock]

Hello,

Owen Taylor wrote:
>  I think it would be really helpful to know a bit more background -
> who
>  are the people developing pkgconf, how did the project start? 
I am one of the primary maintainers of pkgconf.

It started initially, to provide a library interface for various tools to make use of .pc
files
and originally our plan was simply to ship a library containing that machinery and leave
pkg-config itself alone.

That changed when pkg-config 0.26 was released where you now had to go through
special steps to bootstrap pkg-config (due to removal of glib 1.2 code and hard
dependency
on glib 2).

At that point, we decided to build a replacement frontend as well as that happened very
early in the initial development cycle as we did not want to go through those steps to
bootstrap a system.

>  Has there been discussion with the current pkg-config maintainers
> about what they
>  think of this project and whether they would want to retire pkg-config
>  in favor of this project? 
In terms of *retirement* there has been no discussion.  There was some discussion about
formally
specifying the file format in late 2012, but so far hasn’t occurred.

We did announce the existence of the project on the pkg-config mailing list some years
ago, but
the maintainer had no comment on it.  He is aware of the project though, as we have
discussed
with him our position on a few freedesktop.org bugs.

And even still, there are other versions of pkg-config, such as the OpenBSD one.

>  And why is an incompatible 'pkgconf' command line needed in
> addition to
>  the pkg-config wrapper? 
This is an unfortunate description in the change proposal: there is not a separate CLI
client
specific to pkgconf.  The "compatibility wrapper" is just a symlink.

A long time ago, we used to check if we were invoked as "pkg-config" and if so,
disabled some
experimental features (more aggressive linker flags optimizations and a slightly more
conservative
depth limit for the dependency resolver).  In recent years, we have validated both the
linker flags
optimization as well as formally proven and validated that our dependency resolver can
break any
cycle so we no longer do either of these things for several years.

>  If the pkgconf project was the official version of pkg-config and
> they
>  could evolve the 'pkg-config' command line would that be sufficient? 
Unfortunately the cat is out of the bag on this one -- because of the glib2 bootstrapping
issue, there are
several direct forks and reimplementations of pkg-config, notably the Perl implementation
shipped by
OpenBSD, but others exist as well, like Perl's own PkgConfig.pm, and a Python one. 
There is also a Go
pkg-config implementation which has extensions specific to the cgo utility.

>  Having two commands sounds like it will make documentation about
>  anything related to .pc files much more confusing.
>  (And pkg-config vs. /usr/lib/pkgconfig was already confusing...) 
Hopefully above I clarified these points -- we typically use a symlink to allow both
pkgconf
and pkg-config implementations to work alongside each other for comparison reasons.

>  I don't see a problem with pkg-config being rewritten, but I do
> see a
>  problem if there's a fork without a clear direction that is likely to
>  be followed by all distributions. 
The clear direction is pkgconf, some examples of future directions are:

* Providing additional tools to automate the composition of .pc files (based on
  dependency scanning using libelf, for example).
* Integration of libpkgconf into various IDEs and other tools (e.g. CMake)
* Optional plugins infrastructure to support modifying how CFLAGS and
  LIBS entries are expanded (overlinking protections)
* Adding support for more than just CFLAGS and LIBS (cgo-specific flags
  like in the Go version, as an example) and splitting out CPPFLAGS from
  CFLAGS

>  There has to be a single definition of what goes in a .pc file and
> what the interface is,
>  and what happens when you run pkg-config, or use PKG_CHECK_MODULES in a configure.ac
>  file. 
In this area, we do frequent testing of pkgconf git across the entire FreeBSD ports
collection
and Gentoo portage, to ensure that we are not breaking anything.  We are also looking
into
doing the same with an RPM-based distribution (probably Fedora), as well.

Ensuring that we do not break anything while providing a useful, evolutionary path
forward
is really important to us.  In this process we have found and fixed many problems in
various
.pc files as well as improved the robustness of both freedesktop pkg-config as well as
our
own implementation.  A large part of our validation process is from a distributor-centric
point
of view, likely because we developed it to replace pkg-config in a distribution when it
became
much more difficult to bootstrap.

In regards to .pc files being standardized, like I said earlier, it's too late on that
one.  There are
already several variations of the format with use-case specific flags.  What we *can* do
with
libpkgconf is provide a common framework for all of these consumers which can help with
harmonizing the differences these forks have created.

William

[Pavel Raiskup]

Doh I missed this.  This is now approved due to "bootstrapping issue".  So the
way to use "old" pkgconfig is (in case of FTBFS)?

Pavel


On Thursday, January 5, 2017 11:53:38 AM CET Owen Taylor wrote:
>  On Wed, 2017-01-04 at 09:20 +0100, Jan Kurik wrote:
>  > = System Wide Change: pkgconf as system pkg-config implementation =
>  > https://fedoraproject.org/wiki/Changes/pkgconf_as_system_pkg-config_i
>  > mplementation
>  > 
>  > Change owner(s):
>  > * Igor Gnatenko <ignatenkobrain AT fedoraproject DOT org>
>  > * Neal Gompa <ngompa13 AT gmail DOT com>
>  > 
>  > This change switches Fedora's system-wide/default pkg-config
>  > implementation to pkgconf, a new implementation of pkg-config that
>  > provides better support for handling .pc files and a stable library
>  > ABI/API for integrating into applications.
>  
>  I think it would be really helpful to know a bit more background - who
>  are the people developing pkgconf, how did the project start? Has there
>  been discussion with the current pkg-config maintainers about what they
>  think of this project and whether they would want to retire pkg-config
>  in favor of this project?
>  
>  And why is an incompatible 'pkgconf' command line needed in addition to
>  the pkg-config wrapper? If the pkgconf project was the official version
>  of pkg-config and they could evolve the 'pkg-config' command line would
>  that be sufficient? Having two commands sounds like it will make
>  documentation about anything related to .pc files much more confusing.
>  (And pkg-config vs. /usr/lib/pkgconfig was already confusing...)
>  
>  I don't see a problem with pkg-config being rewritten, but I do see a
>  problem if there's a fork without a clear direction that is likely to
>  be followed by all distributions. There has to be a single definition
>  of what goes in a .pc file and what the interface is, and what happens
>  when you run pkg-config, or use PKG_CHECK_MODULES in a configure.ac
>  file.
>  
>  - Owen
>  
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>

[Pavel Raiskup]

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

Pavel

[Neal Gompa]

On Fri, Jan 13, 2017 at 12:20 PM, Pavel Raiskup <praiskup(a)redhat.com&gt; 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.



-- 
真実はいつも一つ！/ Always, there's only one truth!

Diagreement with pkgconfig removal

[Pavel Raiskup]

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(a)redhat.com&gt; 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.

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?

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.

Thanks.
Pavel

Diagreement with pkgconfig removal

[Neal Gompa]

On Sat, Jan 14, 2017 at 7:10 AM, Pavel Raiskup <praiskup(a)redhat.com&gt; 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(a)redhat.com&gt; 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!

Diagreement with pkgconfig removal

[Pavel Raiskup]

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(a)redhat.com&gt; 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(a)redhat.com&gt;
> 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.

Diagreement with pkgconfig removal

[Neal Gompa]

On Sat, Jan 14, 2017 at 9:29 AM, Pavel Raiskup <praiskup(a)redhat.com&gt; wrote:
>  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(a)redhat.com&gt; 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(a)redhat.com&gt;
> 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.;
>  
I strongly believe in Fedora's Foundations[0], which include a
commitment to "excellence" and "innovation". 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.

[0]: https://fedoraproject.org/wiki/Foundations

> > , 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.
>  
Because pkgconf supports the full specification, including Provides
rules. pkgconfig does not. It's been *years* and they never added
support for it. It's even documented to be a stub implementation in
pkgconfig. As a result of pkgconf fully implementing the Provides
rules, .pc files that actually use them will be fully and properly
processed and generate pkgconfig() Provides properly.

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.

> > [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.
>  
To be frank, that has nothing to do with me. If your mirrors aren't
working, there's nothing I can do.

> > 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.
>  
We've done things like this before, and we'll likely do it again. This
is not a valid argument.

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

-- 
真実はいつも一つ！/ Always, there's only one truth!

Diagreement with pkgconfig removal

[Adam Williamson]

On Sat, 2017-01-14 at 09:51 -0500, Neal Gompa wrote:
>  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. 
But...you just said yourself it's not "fully compatible":

"Admittedly, it is less
tolerant of badly written .pc files, but those should be fixed,
anyway."

To me, 'fully compatible' means 'we can switch tomorrow and nothing
will stop building'. It doesn't mean 'compatible with the letter of the
specification'.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

Diagreement with pkgconfig removal

[Neal Gompa]

On Sat, Jan 14, 2017 at 10:30 AM, Adam Williamson
<adamwill(a)fedoraproject.org&gt; wrote:
>  On Sat, 2017-01-14 at 09:51 -0500, Neal Gompa wrote:
> > 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.
>
>  But...you just said yourself it's not "fully compatible":
>  
I should be more clear... It's fully compatible with pkg-config (the
specification) and supports many of the quirks that several pkg-config
implementations have (including pkgconfig), but it isn't bug-for-bug
matching behavior with pkgconfig. The way it handles dependency
resolution is different, and how it merges fragments differs too.

The differences are described pretty well on http://pkgconf.org/features.html

>  "Admittedly, it is less
>  tolerant of badly written .pc files, but those should be fixed,
>  anyway."
>
>  To me, 'fully compatible' means 'we can switch tomorrow and nothing
>  will stop building'. It doesn't mean 'compatible with the letter of the
>  specification'. 
I expect it will be a "we can switch tomorrow and nothing will stop
building" scenario. In terms of behaviors between pkgconf and
pkg-config, the big difference is that Provides stanzas and
Cflags.private stanzas are processed properly in pkgconf, whereas they
are ignored in pkgconfig. In the case of the Provides stanzas, we're
requesting that information for RPM dependency generators, but in
pkgconfig, all it does is return the name of the .pc file without the
file extension and adds the version to it.

As a practical example, LibreSSL provides source compatibility with
OpenSSL 1.0.1. Its .pc file could include Provides stanzas so that
information could be conveyed. In Fedora today, you have to rely on
the .pc files being named exactly the same so that pkgconfig picks
them up. That introduces file conflicts and other things. That would
not be necessary with pkgconf.


-- 
真実はいつも一つ！/ Always, there's only one truth!

Diagreement with pkgconfig removal

[Zbigniew Jędrzejewski-Szmek]

On Sat, Jan 14, 2017 at 10:45:48AM -0500, Neal Gompa wrote:
>  On Sat, Jan 14, 2017 at 10:30 AM, Adam Williamson
>  <adamwill(a)fedoraproject.org&gt; wrote:
>  > On Sat, 2017-01-14 at 09:51 -0500, Neal Gompa wrote:
>  >> 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.
>  >
>  > But...you just said yourself it's not "fully compatible":
>  >
>  
>  I should be more clear... It's fully compatible with pkg-config (the
>  specification) and supports many of the quirks that several pkg-config
>  implementations have (including pkgconfig), but it isn't bug-for-bug
>  matching behavior with pkgconfig. The way it handles dependency
>  resolution is different, and how it merges fragments differs too.
>  
>  The differences are described pretty well on http://pkgconf.org/features.html
>  
>  > "Admittedly, it is less
>  > tolerant of badly written .pc files, but those should be fixed,
>  > anyway."
>  >
>  > To me, 'fully compatible' means 'we can switch tomorrow and nothing
>  > will stop building'. It doesn't mean 'compatible with the letter of the
>  > specification'.
>  
>  I expect it will be a "we can switch tomorrow and nothing will stop
>  building" scenario. In terms of behaviors between pkgconf and
>  pkg-config, the big difference is that Provides stanzas and
>  Cflags.private stanzas are processed properly in pkgconf, whereas they
>  are ignored in pkgconfig. In the case of the Provides stanzas, we're
>  requesting that information for RPM dependency generators, but in
>  pkgconfig, all it does is return the name of the .pc file without the
>  file extension and adds the version to it. 
Hi,

the apparent opposition to this change might come from the relative sparsity
of the "Benefit to Fedora" and "Upgrade/compatibility impact".

In the "Benefit to Fedora" section, it would be nice to have a longer
description: what is the significance of "Provides rules and
Cflags.private rules being supported"? What are the speed changes?

In the mailing list thread use of the library api was mentioned, and
connection to Meson/CMake/something-else. This is not mentioned in the
wiki page at all.

You argue that the change should be mostly painless, but without
providing any details: why not rebuild a 10 or 100 or 1000 packages
in a mock root with pkgconf-pkg-config? Even if there are some minor
hiccups, at least we'll be able to estimate the effort for the whole
archive in the "Upgrade impact" section.

>  As a practical example, LibreSSL provides source compatibility with
>  OpenSSL 1.0.1. Its .pc file could include Provides stanzas so that
>  information could be conveyed. In Fedora today, you have to rely on
>  the .pc files being named exactly the same so that pkgconfig picks
>  them up. That introduces file conflicts and other things. That would
>  not be necessary with pkgconf. 
You argue that the package being ~14 days old is not a reason not to
replace a much older package, still maintained package. I agree, but
it's now a reason to replace it either. There need to be some concrete
benefits for us to *want* to change.

Zbyszek

Diagreement with pkgconfig removal

[Adam Williamson]

On Sat, 2017-01-14 at 19:35 +0000, Zbigniew Jędrzejewski-Szmek wrote:
>  You argue that the change should be mostly painless, but without
>  providing any details: why not rebuild a 10 or 100 or 1000 packages
>  in a mock root with pkgconf-pkg-config? Even if there are some minor
>  hiccups, at least we'll be able to estimate the effort for the whole
>  archive in the "Upgrade impact" section. 
Yes! Exactly this.

In general, I think we really need to be moving away from the 'suck it
and see' approach to distribution development, where we essentially
decide that something sounds like a good idea, then go 'welp, let's see
what happens', throw it in Rawhide, and watch it explode into a million
 tiny pieces, then spend the next month putting the pieces back
together again.

Yes, we've done that before, and yes, we've muddled through. But we
really can do it better these days. We do have better tools and
somewhat more capacity in our systems. There *are* tools for doing
large-scale test builds like this. We *can* even build images from the
test koji tag or whatever and run some automated tests on them, to see
if they work. (If you want to do that, please, come talk to the QA team
about it; we'll help make it happen;it isn't a super-smooth fully-
automated process yet, but we *can* do it, and if it starts becoming a
regular thing, that gives us and the releng team a great motivation to
*make* it a smooth fully-automated process). We have better choices
than "just do it and see what happens". I think it might be good for
folks involved in the Change review process to start asking questions
like "how are we going to see whether this works at all before we land
it in Rawhide mainline?" when reviewing Changes like this in future.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

Diagreement with pkgconfig removal

[William Pitcock]

Hello,

On Sat, Jan 14, 2017 at 2:16 PM, Adam Williamson
<adamwill(a)fedoraproject.org&gt; wrote:
>  On Sat, 2017-01-14 at 19:35 +0000, Zbigniew Jędrzejewski-Szmek
> wrote:
> > You argue that the change should be mostly painless, but without
> > providing any details: why not rebuild a 10 or 100 or 1000 packages
> > in a mock root with pkgconf-pkg-config? Even if there are some minor
> > hiccups, at least we'll be able to estimate the effort for the whole
> > archive in the "Upgrade impact" section.
>
>  Yes! Exactly this.
>
>  In general, I think we really need to be moving away from the 'suck it
>  and see' approach to distribution development, where we essentially
>  decide that something sounds like a good idea, then go 'welp, let's see
>  what happens', throw it in Rawhide, and watch it explode into a million
>   tiny pieces, then spend the next month putting the pieces back
>  together again. 
In general, this is something I agree with.

This is why we do extensive testing of pkgconf to make sure that
betting on pkgconf isn't really a "suck it and see" affair.  We feel
very strong about ensuring that we do not break distributions, and
when we need to make changes that have higher risk of breakage, we
usually provide an LTS branch to use while we sort out a plan for
mitigating the breakage.  This is what I believe responsible
maintenance of a critical toolchain component to be, and is the
maintenance strategy we have used for 5+ years of maintaining pkgconf
as a pkg-config frontend.  In general, we take QA very seriously so
that distributions are confident in our releases.

>  Yes, we've done that before, and yes, we've muddled through.
> But we
>  really can do it better these days. We do have better tools and
>  somewhat more capacity in our systems. There *are* tools for doing
>  large-scale test builds like this. We *can* even build images from the
>  test koji tag or whatever and run some automated tests on them, to see
>  if they work. (If you want to do that, please, come talk to the QA team
>  about it; we'll help make it happen;it isn't a super-smooth fully-
>  automated process yet, but we *can* do it, and if it starts becoming a
>  regular thing, that gives us and the releng team a great motivation to
>  *make* it a smooth fully-automated process). We have better choices
>  than "just do it and see what happens". I think it might be good for
>  folks involved in the Change review process to start asking questions
>  like "how are we going to see whether this works at all before we land
>  it in Rawhide mainline?" when reviewing Changes like this in future. 
I can't really comment on this in regards to Fedora, but my
understanding was this was the submitter's first change like this, so
I suspect he just got a little ahead of himself.  He has been in
#pkgconf on IRC all day setting up a mass test build to verify that
everything will be fine.  If it were my change request, I would likely
have collected that data first, but at least he is trying :)

William

Diagreement with pkgconfig removal

[Neal Gompa]

On Sat, Jan 14, 2017 at 2:35 PM, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl&gt; wrote:
>  On Sat, Jan 14, 2017 at 10:45:48AM -0500, Neal Gompa wrote:
> > On Sat, Jan 14, 2017 at 10:30 AM, Adam Williamson
> > <adamwill(a)fedoraproject.org&gt; wrote:
> > > On Sat, 2017-01-14 at 09:51 -0500, Neal Gompa wrote:
> > >> 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.
> > >
> > > But...you just said yourself it's not "fully compatible":
> > >
> >
> > I should be more clear... It's fully compatible with pkg-config (the
> > specification) and supports many of the quirks that several pkg-config
> > implementations have (including pkgconfig), but it isn't bug-for-bug
> > matching behavior with pkgconfig. The way it handles dependency
> > resolution is different, and how it merges fragments differs too.
> >
> > The differences are described pretty well on http://pkgconf.org/features.html
> >
> > > "Admittedly, it is less
> > > tolerant of badly written .pc files, but those should be fixed,
> > > anyway."
> > >
> > > To me, 'fully compatible' means 'we can switch tomorrow and nothing
> > > will stop building'. It doesn't mean 'compatible with the letter of
> the
> > > specification'.
> >
> > I expect it will be a "we can switch tomorrow and nothing will stop
> > building" scenario. In terms of behaviors between pkgconf and
> > pkg-config, the big difference is that Provides stanzas and
> > Cflags.private stanzas are processed properly in pkgconf, whereas they
> > are ignored in pkgconfig. In the case of the Provides stanzas, we're
> > requesting that information for RPM dependency generators, but in
> > pkgconfig, all it does is return the name of the .pc file without the
> > file extension and adds the version to it.
>
>  Hi,
>
>  the apparent opposition to this change might come from the relative sparsity
>  of the "Benefit to Fedora" and "Upgrade/compatibility impact".
>
>  In the "Benefit to Fedora" section, it would be nice to have a longer
>  description: what is the significance of "Provides rules and
>  Cflags.private rules being supported"? What are the speed changes?
>
>  In the mailing list thread use of the library api was mentioned, and
>  connection to Meson/CMake/something-else. This is not mentioned in the
>  wiki page at all.
>
>  You argue that the change should be mostly painless, but without
>  providing any details: why not rebuild a 10 or 100 or 1000 packages
>  in a mock root with pkgconf-pkg-config? Even if there are some minor
>  hiccups, at least we'll be able to estimate the effort for the whole
>  archive in the "Upgrade impact" section.
>  
I had done some tests locally before, but a DNF bug[1] made it so it
didn't work in COPR, as the host DNF is 1.1.x and afflicted with the
issue (I use DNF 2.0 locally). I worked around it (see dummy empty
pkgconfig package that just pulls in pkgconf-pkg-config) so that I
could publish some test builds through COPR[2]. I've gone through a
few packages that explicitly BuildRequire pkgconfig (using "dnf
repoquery --source --whatrequires 'pkgconfig'" to identify them) as
well as one or two that I just felt like throwing into the mix. I'll
probably keep throwing more random things into there, but you can see
that so far, they've all been successful, using pkgconf as the
pkg-config implementation, with no loss in generated data in terms of
pkgconfig() Provides and Requires, and no build systems have fallen
over when using pkgconf.

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1332830
[2]: https://copr.fedorainfracloud.org/coprs/ngompa/f26-pkgconf/builds/




-- 
真実はいつも一つ！/ Always, there's only one truth!

Diagreement with pkgconfig removal

[William Pitcock]

Hi,

On Sat, Jan 14, 2017 at 9:30 AM, Adam Williamson
<adamwill(a)fedoraproject.org&gt; wrote:
>  On Sat, 2017-01-14 at 09:51 -0500, Neal Gompa wrote:
> > 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.
>
>  But...you just said yourself it's not "fully compatible":
>
>  "Admittedly, it is less
>  tolerant of badly written .pc files, but those should be fixed,
>  anyway."
>
>  To me, 'fully compatible' means 'we can switch tomorrow and nothing
>  will stop building'. It doesn't mean 'compatible with the letter of the
>  specification'. 
In practice, this is the case already.  We (pkgconf upstream) do tests
across FreeBSD ports, Gentoo portage tree to ensure there are no
regressions in any of the released versions.

The reason why we say this is there's a lot of proprietary software
that uses pkg-config as part of it's build process, and the .pc files
that we have encountered from those guys are usually quite wrong.

As for how this relates to Fedora, it's not really my place to say --
but we are planning to do the same testing with Fedora as well.

William

Diagreement with pkgconfig removal

[Pavel Raiskup]

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

Diagreement with pkgconfig removal

[Neal Gompa]

On Sat, Jan 14, 2017 at 10:58 AM, Pavel Raiskup <praiskup(a)redhat.com&gt; 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.
>  
Gentoo and Debian have both pkgconfig and pkgconf, so it's not unheard of.

> > 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.
>  
It was mentioned earlier in the thread that pkgconf was not originally
planned to provide a frontend interface (it was intended to be a
library). But when pkgconfig introduced the glib2 dependency, making
it difficult to build and bootstrap, pkgconf grew a CLI program to act
as a replacement.

Yes, it's licensed ISC, which is more palatable for BSDs, but everyone
was mostly okay with pkgconfig until the glib2 dependency was
introduced (and not even for a good reason, like offering a library
with g-i support). After that happened, lots of independent
implementations showed up (OpenBSD's implementation in Perl, which
lacks Conflicts support, Perl and Python implementations as modules
implementing subsets for archful builds, etc.). pkgconf intends to
offer a uniform interface for all types of applications that leverage
the pkg-config specification.

> > 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?
>  
I don't think so. The Provides rules support was added because I asked
for it, because there were cases where it makes complete sense to have
them. The Cflags.Requires feature was a feature request to pkgconfig 3
years ago[1] that went nowhere and led to the project in question
requesting it to switch to pkgconf. There are plenty of long-living
bugs that haven't been addressed in a while in pkgconfig[2].

[1]: https://bugzilla.freedesktop.org/show_bug.cgi?id=47996

[2]:
https://bugzilla.freedesktop.org/buglist.cgi?component=src&product=pk...

> > 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.
>  
We could certainly retain both implementations, but it we would need
to decide on an approach on how to keep both.

Two ways to do it:

1. Use alternatives. This is how Debian does it. I think this is
probably a bad idea because it's very possible to get inconsistent
results due to the differences of the two resolvers, depending on how
someone builds locally. The missing features in pkgconfig could lead
to a bad experience, too.

2. Rename the conflicting files in pkgconfig. I'd prefer this
approach, as then people can explicitly use it though the mechanisms
I've mentioned earlier in the thread.



-- 
真実はいつも一つ！/ Always, there's only one truth!

Diagreement with pkgconfig removal

[William Pitcock]

Hello,

On Sat, Jan 14, 2017 at 9:58 AM, Pavel Raiskup <praiskup(a)redhat.com&gt; 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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org

Diagreement with pkgconfig removal

[Kevin Kofler]

Pavel Raiskup wrote:
>  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. 
It's not "no reason". The reason is to provide a drop-in replacement, which

necessarily requires using the same binary name. At that point, 
Obsoletes/Provides is just the most effective solution to the file conflict 
that would ensue, also ensuring the upgrade path to the new default for 
users of older Fedora releases.

        Kevin Kofler

Diagreement with pkgconfig removal

[Frank Ch. Eigler]

praiskup wrote:

>  [...]
>  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. 
... and also let's make sure that the new package does not break builds.
For one of ours, the .spec file contained:

BuildRequires: pkgconfig
BuildRequires: foo-devel

Yes, this is not canonical pkgconfig(foo) & perfect & stuff, but it's
worked for years.  With the new changes, it breaks builds:
[...] https://kojipkgs.fedoraproject.org//work/tasks/2704/17392704/root.log

DEBUG util.py:421:  Error: package
pkgconf-pkg-config-1.2.0-1.fc26.aarch64 conflicts with pkgconfig <
1:0.29.1-2 provided by pkgconfig-1:0.29.1-1.fc25.aarch64


- FChE

Diagreement with pkgconfig removal

[Igor Gnatenko]

On Mon, 2017-01-23 at 11:10 -0500, Frank Ch. Eigler wrote:
>  praiskup wrote:
>  
>  > [...]
>  > 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.
>  
>  ... and also let's make sure that the new package does not break
>  builds.
>  For one of ours, the .spec file contained:
>  
>  BuildRequires: pkgconfig
>  BuildRequires: foo-devel
>  
>  Yes, this is not canonical pkgconfig(foo) & perfect & stuff, but it's
>  worked for years.  With the new changes, it breaks builds:
>  [...] https://kojipkgs.fedoraproject.org//work/tasks/2704/17392704/ro
>  ot.log
>  
>  DEBUG util.py:421:  Error: package
>  pkgconf-pkg-config-1.2.0-1.fc26.aarch64 conflicts with pkgconfig <
>  1:0.29.1-2 provided by pkgconfig-1:0.29.1-1.fc25.aarch64 
This is known issue (not
really caused by pkgconf change, but it is
caused by bug in dnf), see: https://pagure.io/releng/issue/6597
>  
>  
>  - FChE
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org 
-- 
-Igor Gnatenko

Diagreement with pkgconfig removal

[Kevin Fenzi]

On Mon, 23 Jan 2017 11:10:59 -0500
fche(a)redhat.com (Frank Ch. Eigler) wrote:

>  praiskup wrote:
>  
>  > [...]
>  > 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.  
>  
>  ... and also let's make sure that the new package does not break
>  builds. For one of ours, the .spec file contained:
>  
>  BuildRequires: pkgconfig
>  BuildRequires: foo-devel
>  
>  Yes, this is not canonical pkgconfig(foo) & perfect & stuff, but it's
>  worked for years.  With the new changes, it breaks builds:
>  [...]
>  https://kojipkgs.fedoraproject.org//work/tasks/2704/17392704/root.log
>  
>  DEBUG util.py:421:  Error: package
>  pkgconf-pkg-config-1.2.0-1.fc26.aarch64 conflicts with pkgconfig <
>  1:0.29.1-2 provided by pkgconfig-1:0.29.1-1.fc25.aarch64 
This will be fixed soon (today hopefully) without you needing to make
any more changes. 

We need to get dnf updated on the aarch64/ppc64/ppc64le builders. 

kevin

Diagreement with pkgconfig removal

[Björn Persson]

Neal Gompa wrote:
>  Because pkgconf supports the full specification, including Provides
>  rules. pkgconfig does not. It's been *years* and they never added
>  support for it. It's even documented to be a stub implementation in
>  pkgconfig. As a result of pkgconf fully implementing the Provides
>  rules, .pc files that actually use them will be fully and properly
>  processed and generate pkgconfig() Provides properly. 
Where is this specification you keep talking about, and who wrote it?
The specifications I can find are
https://people.freedesktop.org/~dbn/pkg-config-guide.html and "man 1
pkg-config". Neither of those mention a field named Provides.

Is there disagreement about what the file format is? It could be very
bad if multiple incompatible variants of .pc files would arise so that
different libraries would require different pkg-config programs.

Björn Persson

Diagreement with pkgconfig removal

[Neal Gompa]

On Sat, Jan 14, 2017 at 1:46 PM, Björn Persson <Bjorn(a)xn--rombobjrn-67a.se&gt; wrote:
>  Neal Gompa wrote:
> > Because pkgconf supports the full specification, including Provides
> > rules. pkgconfig does not. It's been *years* and they never added
> > support for it. It's even documented to be a stub implementation in
> > pkgconfig. As a result of pkgconf fully implementing the Provides
> > rules, .pc files that actually use them will be fully and properly
> > processed and generate pkgconfig() Provides properly.
>
>  Where is this specification you keep talking about, and who wrote it?
>  The specifications I can find are
>  https://people.freedesktop.org/~dbn/pkg-config-guide.html and "man 1
>  pkg-config". Neither of those mention a field named Provides.
>  
Hmm. I guess the only reference to it is with the --print-provides switch.

>  Is there disagreement about what the file format is? It could be
> very
>  bad if multiple incompatible variants of .pc files would arise so that
>  different libraries would require different pkg-config programs.
>  
I believe there's been a bit of that lately as well... It was briefly
mentioned earlier in the thread by the pkgconf author.

As it turns out, a formal spec was requested a while ago[1], with
pkgconfig and pkgconf upstream both talking in there, but it went
nowhere too...

[1]: https://bugs.freedesktop.org/show_bug.cgi?id=63747


-- 
真実はいつも一つ！/ Always, there's only one truth!

Diagreement with pkgconfig removal

[William Pitcock]

Hello,

On Sat, Jan 14, 2017 at 12:46 PM, Björn Persson <Bjorn(a)xn--rombobjrn-67a.se&gt; wrote:
>  Neal Gompa wrote:
> > Because pkgconf supports the full specification, including Provides
> > rules. pkgconfig does not. It's been *years* and they never added
> > support for it. It's even documented to be a stub implementation in
> > pkgconfig. As a result of pkgconf fully implementing the Provides
> > rules, .pc files that actually use them will be fully and properly
> > processed and generate pkgconfig() Provides properly.
>
>  Where is this specification you keep talking about, and who wrote it?
>  The specifications I can find are
>  https://people.freedesktop.org/~dbn/pkg-config-guide.html and "man 1
>  pkg-config". Neither of those mention a field named Provides.
>
>  Is there disagreement about what the file format is? It could be very
>  bad if multiple incompatible variants of .pc files would arise so that
>  different libraries would require different pkg-config programs. 
There are already incompatible variants of .pc files :(

For example, there is a variant of .pc files for Go programs that adds
Go-specific fields and variables to the format.
The Perl and Python implementations also elide details that are not
directly relevant to them.

But lets look at why Go, Perl and Python have native implementations:
it's because they lacked bindings to pkg-config that would allow them
to programmatically manipulate .pc files -- all they had to work with
was the output of pkg-config, which makes mapping the CFLAGS etc onto
their own internal build architectures a lot more difficult.

In my opinion pkgconf + libpkgconf is the way out of this mess because
everyone can use the common infrastructure for their needs, and that
is the direction the Perl guys are already moving in.

William

Diagreement with pkgconfig removal

[Yaakov Selkowitz]

On 2017-01-14 06:45, Neal Gompa wrote:
>  On Sat, Jan 14, 2017 at 7:10 AM, Pavel Raiskup
> <praiskup(a)redhat.com&gt; 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(a)redhat.com&gt;
> 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. 
What about mingw-pkg-config?  Using pkgconf for a cross-pkg-config is a 
bit more work because of the library (in which the default search path 
is hardcoded) would then need to be built statically into the binary, 
and subsequently not installed so as to not conflict with the "native" 
libpkgconf.

That being said, I wonder if embedding the default search path into the 
library isn't a mistake in design, as it does not prevent the need for 
multiple copies of the same code as in the above example.  Instead, if 
the library were to be path agnostic and shipped separately, and the 
default search paths set by the consumers, then a cross-pkgconf could 
use such a libpkgconf.

>  The other big advantage of pkgconf is the library. 
Which is already available, and does not require completely replacing 
pkg-config with pkgconf.


-- 
Yaakov Selkowitz
Software Engineer - Platform Enablement Group
Red Hat, Inc.

Diagreement with pkgconfig removal

[William Pitcock]

Hello,

On Mon, Jan 23, 2017 at 1:10 PM, Yaakov Selkowitz <yselkowi(a)redhat.com&gt; wrote:
>  On 2017-01-14 06:45, Neal Gompa wrote:
> >
> > On Sat, Jan 14, 2017 at 7:10 AM, Pavel Raiskup <praiskup(a)redhat.com&gt;
> > 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(a)redhat.com&gt;
> >>> 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.
>
>
>  What about mingw-pkg-config?  Using pkgconf for a cross-pkg-config is a bit
>  more work because of the library (in which the default search path is
>  hardcoded) would then need to be built statically into the binary, and
>  subsequently not installed so as to not conflict with the "native"
>  libpkgconf.
>
>  That being said, I wonder if embedding the default search path into the
>  library isn't a mistake in design, as it does not prevent the need for
>  multiple copies of the same code as in the above example.  Instead, if the
>  library were to be path agnostic and shipped separately, and the default
>  search paths set by the consumers, then a cross-pkgconf could use such a
>  libpkgconf. 
It is possible to override the default at runtime inside libpkgconf.
The default is only used if you do not install a search path prior to
calling pkgconf_pkg_dir_list_build().

An easier way is to use the PKG_CONFIG_LIBDIR and PKG_CONFIG_PATH
environmental variables, which can be used by cross wrappers to
completely replace the default.
PKG_CONFIG_LIBDIR is the fallback paths, which PKG_CONFIG_PATH are the
site paths.
This approach also works with pkg-config but I don't know to what
extent it is formally supported there.

Feel free to drop by #pkgconf in freenode IRC if you have questions
about it, I'm quite certain we can find a solution that will work for
you.

William