Hello,
On Mon, Jan 23, 2017 at 1:10 PM, Yaakov Selkowitz <yselkowi(a)redhat.com> 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>
> 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.
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