On 2017-01-14 06:45, Neal Gompa wrote:
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.
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.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
