Re: Diagreement with pkgconfig removal

[William Pitcock]

Hello,

On Mon, Jan 23, 2017 at 1:10 PM, Yaakov Selkowitz  wrote:
> On 2017-01-14 06:45, Neal Gompa wrote:
>>
>> On Sat, Jan 14, 2017 at 7:10 AM, Pavel Raiskup 
>> 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 
 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: 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  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  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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: 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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
-- 
-Igor Gnatenko
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Diagreement with pkgconfig removal

[Kevin Fenzi]

On Mon, 23 Jan 2017 11:10:59 -0500
f...@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


pgpN3WRzPd7kE.pgp
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Diagreement with pkgconfig removal

[Neal Gompa]

On Sat, Jan 14, 2017 at 2:35 PM, Zbigniew Jędrzejewski-Szmek
 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
>>  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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Diagreement with pkgconfig removal

[William Pitcock]

Hello,

On Sat, Jan 14, 2017 at 12:46 PM, Björn Persson  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Diagreement with pkgconfig removal

[William Pitcock]

Hello,

On Sat, Jan 14, 2017 at 9:58 AM, Pavel Raiskup  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 

Re: Diagreement with pkgconfig removal

[William Pitcock]

Hello,

On Sat, Jan 14, 2017 at 2:16 PM, Adam Williamson
 wrote:
> On Sat, 2017-01-14 at 19:35 +, 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Diagreement with pkgconfig removal

[William Pitcock]

Hi,

On Sat, Jan 14, 2017 at 9:30 AM, Adam Williamson
 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Diagreement with pkgconfig removal

[Adam Williamson]

On Sat, 2017-01-14 at 19:35 +, 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: 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
>  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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Diagreement with pkgconfig removal

[Neal Gompa]

On Sat, Jan 14, 2017 at 1:46 PM, Björn Persson  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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: 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


pgp3gXCZrvIfJ.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Diagreement with pkgconfig removal

[Neal Gompa]

On Sat, Jan 14, 2017 at 10:58 AM, Pavel Raiskup  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=pkg-config=---

>> 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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Diagreement with pkgconfig removal

[Neal Gompa]

On Sat, Jan 14, 2017 at 10:30 AM, Adam Williamson
 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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Diagreement with pkgconfig removal

[Neal Gompa]

On Sat, Jan 14, 2017 at 9:29 AM, Pavel Raiskup  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  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  
>> >> 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 

Re: 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  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  
> >> 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 

Re: Diagreement with pkgconfig removal

[Neal Gompa]

On Sat, Jan 14, 2017 at 7:10 AM, Pavel Raiskup  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  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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org