On 2017-01-14 06:45, Neal Gompa wrote:
On Sat, Jan 14, 2017 at 7:10 AM, Pavel Raiskup
<praiskup(a)redhat.com> 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>
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.