Re: Diagreement with pkgconfig removal

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

 



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@xxxxxxxxxxxxxxxxx> 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
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




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